使用 Apache Kafka 的 MirrorMaker 迁移集群 - Amazon Managed Streaming for Apache Kafka
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅中国的 Amazon Web Services 服务入门

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

使用 Apache Kafka 的 MirrorMaker 迁移集群

可以使用 MirrorMaker(它是 Apache Kafka 的一部分)镜像或迁移集群。例如,可以使用它将 Apache Kafka 集群迁移到 Amazon MSK 集群或从一个 MSK 集群。有关如何使用 MirrorMaker 的信息,请参阅 Apache Kafka 文档中的在集群间镜像数据。我们建议您在高可用性配置中设置 MirrorMaker。

使用 MirrorMaker 迁移到时要执行的步骤的概述

  1. 创建目标 MSK 群集

  2. 从目标集群所在的同一 Amazon VPC 中的 Amazon EC2 实例启动 MirrorMaker。

  3. 检查 MirrorMaker 滞后。

  4. 在 MirrorMaker 跟上之后,使用 MSK 集群引导代理将创建器和使用器重定向到新的集群。

  5. 关闭 MirrorMaker。

将 Apache Kafka 集群迁移到亚马逊 MSK

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

将现有的 Apache Kafka 集群迁移到亚马逊 MSK 集群

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

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

  2. 从具有 CLUSTER_ONPREM 的读访问权和 CLUSTER_AWSMSK 的写访问权的实例启动 MirrorMaker。

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

    ./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:9092config/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 将 MSK 集群迁移到另一个集群。例如,您可以从一个版本的 Apache Kafka 迁移到另一个版本的 Apache Kafka。有关如何使用 Amazon CloudFormation 执行此操作的示例,请参阅 AWS::MSK::Cluster 示例(搜索名为 Create Two MSK Clusters To Use With Apache MirrorMaker 的示例)。

MirrorMaker 1.0 最佳实践

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

  • 在目标集群上运行 MirrorMaker。这样一来,如果发生网络问题,消息仍在源集群中可用。如果您在源集群上运行 MirrorMaker,在创建器中缓冲事件且存在网络问题,ze 事件可能会丢失。

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

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

  • 对于创建器,设置

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

    • retries=Int.Max_Value

    • acks=all

    • max.block.ms = Long.Max_Value

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

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

    • 调整套接字缓冲区 — 接收 .buffer.bytes、send.buffer.bytes

  • 为了避免数据丢失,请在源上关闭自动提交,以便 MirrorMaker 能够控制提交,这通常是在从目标集群收到 ack 后进行的。如果创建器的 acks=all 且目标集群的 min.insync.replicas 设置为大于 1,则在 MirrorMaker 使用器在源上提交偏移之前,这些消息将在目标上的多个代理上持久保存。

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

  • 对于高吞吐量

    • 增加 buffer.memory。

    • 增大批处理大小。

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

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

  • 对于高使用器吞吐量

    • 增加每个 MirrorMaker 进程的线程/使用器数 — 数目流。

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

    • 依次增加同一台计算机和其他计算机(具有相同的组 ID)上的 MirrorMaker 进程数。

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

  • 对于管理和配置

    • 使用 Amazon CloudFormation 和配置管理工具,如 Chef 和 Ansible。

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

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

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

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

MirrorMaker 2.* 的优势

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

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

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

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

  • 提供新指标,包括跨多个数据中心和集群的端到端复制延迟。

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

  • 支持高级配置文件,以实现在一个位置指定多个集群和复制流,这与为每个 MirrorMaker 1.* 进程单独指定低级创建器/使用器属性不同。