对主 Amazon 区域执行失效自动恢复

如果使用相同主题名称复制配置，请按照以下步骤操作：

1. 创建一个新的 MSK 复制器，将辅助集群作为源，主集群作为目标，起始位置设置为最早，且使用相同主题名称复制（控制台中为保留相同的主题名称）。

   这将启动将失效转移后写入辅助群集的所有数据复制回主区域的过程。

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

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

4. 等待连接到辅助集群的使用者的 MaxOffsetLag 指标变成 0，以确保它们已处理完所有数据。请参阅 监控消费者延迟。

5. 所有数据处理完毕后，停止辅助区域中的消费者并启动连接到主集群的消费者以完成失效自动恢复。

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

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

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

如果使用带前缀主题名称配置，请按照以下步骤进行操作：

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

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

2. 对于主动-被动拓扑，请删除正在将数据从二级区域的集群复制到主区域的复制器。对于主动-主动拓扑，您无需删除复制器。

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

4. 请按照以下选项卡之一的步骤操作，具体取决于应用程序的消息排序要求。

   No message ordering

   如果您的应用程序不需要消息排序，则在主 Amazon 区域中启动使用通配符运算符（例如topic）同时读取本地（例如<sourceKafkaClusterAlias>.topic）和复制主题（例如.*topic）的使用者。本地主题（例如 topic）的使用器将从失效转移前消耗的最后一个偏移恢复。如果在失效转移之前有任何未处理的数据，则现在将对其进行处理。如果是计划内失效转移，则不应有此类记录。

   Message ordering

   1. 仅为主区域上复制的主题（例如 <sourceKafkaClusterAlias>.topic）启动使用器，而不为本地主题（例如 topic）启动使用器。

   2. 等待主区域集群上所有已复制主题的使用器完成所有数据的处理，这样偏移延迟为 0，处理的记录数也为 0。然后，停止主区域集群上已复制主题的使用器。此时，失效转移后在二级区域生成的所有记录都已在主区域中使用。

   3. 在主区域的集群上启动本地主题（例如 topic）的使用器。

5. 使用 ReplicatorThroughput 和 latency 指标，验证从主区域中的集群到复制区域中的集群的现有复制器是否处于 RUNNING 状态并按预期运行。