迁移到 Amazon MSK 集群

Amazon MSK 复制器可用于 MSK 集群迁移。请参阅 什么是 Amazon MSK 复制器？。或者，您可以使用 Apache MirrorMaker 2.0 从非 MSK 集群迁移到 Amazon MSK 集群。有关如何执行此操作的示例，请参阅使用将本地 Apache Kafka 集群迁移到 Amazon MSK。 MirrorMaker有关如何使用的信息 MirrorMaker，请参阅 Apache Kafka 文档中的在集群之间镜像数据。我们建议使用高可用 MirrorMaker 性配置进行设置。

使用迁移到 MSK 集群时 MirrorMaker 应遵循的步骤概述

1. 创建目标 MSK 集群

2. MirrorMaker 从与目标集群位于同一 Amazon VPC 中的亚马逊 EC2 实例开始。

3. 检查延 MirrorMaker 迟。

4. MirrorMaker 赶上之后，使用 MSK 集群引导代理将生产者和使用者重定向到新集群。

5. 关掉 MirrorMaker。

将 Apache Kafka 集群迁移到 Amazon MSK

假定您有一个名为 CLUSTER_ONPREM 的 Apache Kafka 集群。该集群中已填充主题和数据。如果要将该集群迁移到新创建的名为 CLUSTER_AWSMSK 的 Amazon MSK 集群，此程序将提供您需要执行之步骤的高级视图。

将现有的 Apache Kafka 集群迁移到 Amazon MSK

1. 在 CLUSTER_AWSMSK 中，创建要迁移的所有主题。

   您不能使用 MirrorMaker 此步骤，因为它不会自动使用正确的复制级别重新创建要迁移的主题。您可以使用与 CLUSTER_ONPREM 中相同的复制因子和分区数在 Amazon MSK 中创建主题。也可以创建具有不同的复制因子和分区数的主题。

2. MirrorMaker 从具有读取权限CLUSTER_ONPREM和写入权限的实例开始CLUSTER_AWSMSK。

3. 运行以下命令以镜像所有主题：

   <path-to-your-kafka-installation>/bin/kafka-mirror-maker.sh --consumer.config config/mirrormaker-consumer.properties --producer.config config/mirrormaker-producer.properties --whitelist '.*'

   在此命令中，config/mirrormaker-consumer.properties 指向 CLUSTER_ONPREM 中的引导代理；例如，bootstrap.servers=localhost:9092。并config/mirrormaker-producer.properties指向 CLUSTER_ 中的引导程序代理AWSMSK；例如，。bootstrap.servers=10.0.0.237:9092,10.0.2.196:9092,10.0.1.233:9092

4. 继续在后台 MirrorMaker 运行，然后继续使用CLUSTER_ONPREM。 MirrorMaker 镜像所有新数据。

5. 通过检查每个主题的最后一个偏移量与当前消耗的偏移量之间的延迟，来检查镜像的进度。 MirrorMaker

   请记住，这只 MirrorMaker 是在使用消费者和生产者。因此，您可以使用 kafka-consumer-groups.sh 工具检查滞后。要查找使用器组名称，请在 mirrormaker-consumer.properties 文件中查找 group.id，然后使用其值。如果文件中没有此类密钥，您可以创建它。例如，设置 group.id=mirrormaker-consumer-group。

6. 镜像 MirrorMaker 完所有主题后，停止所有生产者和消费者，然后停止 MirrorMaker。然后，将创建器和使用器重定向到 CLUSTER_AWSMSK 集群，方式是更改该集群的创建器和使用器引导代理值。在 CLUSTER_AWSMSK 上重新启动所有创建器和使用器。

在 Amazon MSK 集群之间迁移

您可以使用 Apache MirrorMaker 2.0 从非 MSK 集群迁移到 MSK 集群。例如，您可以从一个版本的 Apache Kafka 迁移到另一个版本的 Apache Kafka。有关如何执行此操作的示例，请参阅使用将本地 Apache Kafka 集群迁移到 Amazon MSK。 MirrorMakerAmazon MSK 复制器还可用于 MSK 集群迁移。有关 Amazon MSK 复制器的更多信息，请参阅 MSK 复制器。

MirrorMaker 1.0 最佳实践

此最佳实践列表适用于 MirrorMaker 1.0。

• 在目标集群 MirrorMaker 上运行。这样一来，如果发生网络问题，消息仍在源集群中可用。如果您在源集群 MirrorMaker 上运行，并且事件在生产者中进行缓冲，并且存在网络问题，则事件可能会丢失。

• 如果传输过程中需要加密，请在源集群中运行 MirrorMaker。

• 对于使用器，设置 auto.commit.enabled=false

• 对于创建器，设置

  • max.in.flight.requests.per.connection=1

  • retries=Int.Max_Value

  • acks=all

  • max.block.ms = Long.Max_Value

• 对于较高的创建器吞吐量：

  • 缓冲区消息和填充消息批处理 – 调整 buffer.memory、batch.size、linger.ms

  • 调整套接字缓冲区 – receive.buffer.bytes、send.buffer.bytes

• 为避免数据丢失，请在源端关闭 auto commit，这样它 MirrorMaker 就可以控制提交，这通常是在收到来自目标集群的 ack 之后才会这样做。如果生产者具有 acks=all 并且目标集群将 min.insync.replicas 设置为大于 1，则在使用者在源端提交偏移量之前，消息将保留在目标的多个代理上。 MirrorMaker

• 如果顺序很重要，则可将重试次数设置为 0。或者，对于生产环境，将最大传输中连接数设置为 1，以确保在批处理中途失败时，不会无序提交发出的批处理。这样一来，将重试发送的每个批处理，直到发出下一个批处理为止。如果 max.block.ms 未设置为最大值，并且如果创建器缓冲区已满，则可能会丢失数据（具体取决于其他一些设置）。这可以阻止和反压使用器。

• 对于高吞吐量

  • 增加 buffer.memory。

  • 增大批处理大小。

  • 调整 linger.ms 以允许填充批处理。这还可以实现更好的压缩、更少的网络带宽用量以及更少的集群存储。这会导致提高保留率。

  • 监控 CPU 和内存使用情况。

• 对于高使用器吞吐量

  • 增加每个 MirrorMaker 进程的线程/使用者数量 — num.streams。

  • 在增加线程之前，先增加计算机间的 MirrorMaker 进程数量，以实现高可用性。

  • 首先在同一台计算机上增加 MirrorMaker 进程数，然后在不同的计算机上增加进程数（使用相同的组 ID）。

  • 隔离吞吐量非常高的主题并使用单独的 MirrorMaker 实例。

• 对于管理和配置

  • 使用 AWS CloudFormation 和配置管理工具，比如 Chef 和 Ansible。

  • 使用 Amazon EFS 装载以确保可从所有 Amazon EC2 实例访问所有配置文件。

  • 使用容器轻松扩展和管理实 MirrorMaker例。

• 通常，需要不止一个消费者才能使一个生产者饱和。 MirrorMaker因此，请设置多个使用器。首先，在不同的计算机上设置使用器以实现高可用性。然后，扩展各个计算机以使每个分区有一个使用器，并且使用器在各个计算机之间均匀分配。

• 对于高吞吐量提取和传输，请调整接收和发送缓冲区，因为它们的默认值可能太小了。为了获得最佳性能，请确保流的总数 (num.streams) 与尝试复制到目标集群的所有主题分区相 MirrorMaker 匹配。

MirrorMaker 2.* 优点

• 可以利用 Apache Kafka Connect 框架和生态系统。

• 可以检测新主题和分区。

• 可以在集群之间自动同步主题配置。

• 支持“主动/主动”集群对以及任意数量的主动集群。

• 提供新的指标，包括跨多个数据中心和集群的 end-to-end 复制延迟。

• 提供在集群之间迁移使用器所需的偏移量，并提供偏移量转换工具。

• 与每 MirrorMaker 个 1.* 进程的低级生产者/使用者属性相比，支持用于在一个位置指定多个集群和复制流程的高级配置文件。