本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 故障恢复
<a name="msk-replicator-failback"></a>

在主 AWS 区域的服务事件结束后，您可以回切到该区域。

------
#### [ Identical topic name replication ]

1. 创建一个新的 MSK 复制器，将辅助集群作为源，主集群作为目标，起始位置设置为*最早*，且使用相同主题名称复制（控制台中为**保留相同的主题名称**）。这将在故障转移回主区域后开始复制写入辅助群集的所有数据。

1. 在 Amazon 中监控新复制器上的`MessageLag`指标， CloudWatch 直到达到该指标`0`，这表明所有数据都已从辅助复制到主副本。

1. 所有数据复制完成后，停止所有连接到辅助集群的生产者，并启动连接到主集群的生产者。

1. 等待连接到辅助集群的使用者的`MaxOffsetLag`指标变成`0`，以确保他们已处理了所有数据。请参阅[监控消费者延迟](consumer-lag.md)。

1. 处理完所有数据后，停止辅助区域中的使用者，然后启动消费者连接到主集群以完成故障恢复。

1. 删除在第一步中创建的将数据从辅助集群复制到主集群的复制器。

1. 验证将数据从主集群复制到辅助集群的现有 Replicator 的状态是否为 “正在运行”，并且 Amazon 中的`ReplicatorThroughput`指标 CloudWatch 是否大于`0`。

   请注意，当您创建起始位置为 “*最早*进行故障恢复” 的新 Replicator 时，它会开始读取辅助群集主题中的所有数据。根据您的数据留存设置，您的主题可能包含来自源集群的数据。虽然 MSK 复制器会自动筛选这些消息，但是您仍将为辅助集群中的所有数据支付数据处理和传输费用。您可以使用 `ReplicatorBytesInPerSec` 跟踪复制器处理的总数据。

------
#### [ Prefixed topic name replication ]

只有在从辅助区域的集群复制到主区域的集群已赶上并且 Amazon 中的`MessageLag`指标接近 0 之后， CloudWatch 才应启动故障恢复步骤。计划的失效自动恢复不应导致数据丢失。

1. 关闭所有连接到二级区域中 MSK 集群的生成器和使用器。

1. 对于主动-被动拓扑，请删除将数据从辅助区域的群集复制到主区域的复制器。对于主动-主动拓扑，您无需删除复制器。

1. 启动连接到主区域中 MSK 集群的生成器。

1. 如果您的应用程序不需要消息排序，请在主 AWS 区域启动使用通配符运算符同时读取本地和复制主题的使用者。如果您的应用程序需要消息排序，请先仅为复制的主题启动使用者，等待延迟达到 0，然后切换到本地主题。

1. 使用和延迟指标验证从主区域的群集到辅助区域的群集的现有 Replicator 是否处于 RUNNING 状态`ReplicatorThroughput`并按预期运行。

------