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

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

使用ApacheKafka迁移群集 MirrorMaker

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

使用 MirrorMaker 迁移到 MSK 集群

  1. 创建目标 MSK 集群

  2. 开始 MirrorMaker 从 Amazon EC2 实例 Amazon VPC 作为目标群集。

  3. 检查 MirrorMaker 滞后。

  4. 之后 MirrorMaker 使用MSK群集bootstrapbroker,将生产者和消费者重新引导到新群集。

  5. 关闭 MirrorMaker.

将 Apache Kafka 集群迁移到 Amazon MSK

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

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

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

    无法使用 MirrorMaker ,因为它不会自动创建您要以正确的复制级别迁移的主题。您可以在以下位置创建主题: Amazon MSK 具有相同的复制因子和分区数量 CLUSTER_ONPREM。您还可以创建具有不同复制因子和分区数量的主题。

  2. 开始 MirrorMaker 从具有读取访问权限的实例 CLUSTER_ONPREM 并写入访问 CLUSTER_AWSMSK.

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

    ./bin/kafka-mirror-maker.sh --consumer.config config/mirrormaker-consumer.properties --producer.config config/mirrormaker-producer.properties --whitelist '.*'

    在此命令中, config/mirrormaker-consumer.properties 指向中的bootstrapbroker CLUSTER_ONPREM例如, bootstrap.servers=localhost:9092。以及 config/mirrormaker-producer.properties 指向CLUSTER_AWSMSK中的bootstrapbroker;例如, 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 通过更改其生产者和消费者bootstrapbroker的值来集群。在 CLUSTER_AWSMSK 上重新启动所有创建器和使用器。

从一个 Amazon MSK 集群迁移到另一个 Amazon MSK 集群

您可以使用Apache MirrorMaker 迁移 MSK 集群 到另一个群集。例如,您可以从一个版本的 Apache Kafka 迁移到另一个版本的 Apache Kafka。有关如何使用 AWS CloudFormation 执行此操作的示例,请参阅 AWS::MSK::Cluster 示例(搜索名为 Create Two MSK Clusters To Use With Apache MirrorMaker 的示例)。

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

  • 为避免数据丢失,请关闭源头的自动提交,以便 MirrorMaker 可以控制提交,通常在从目标群集接收到确认请求后执行。如果生成程序的acks=all且目标群集的min.insync.replicas设置为1个以上,则消息在 MirrorMaker 消费者在源处提交偏移。

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

  • 对于高吞吐量

    • 增加 buffer.memory。

    • 增大批处理大小。

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

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

  • 对于高使用器吞吐量

    • 增加每个 MirrorMaker 流程 — 数量流。

    • 增加 MirrorMaker 在增加线程之前先跨机器处理,以允许高可用性。

    • 增加 MirrorMaker 先在同一台计算机上处理,然后再在不同计算机上处理(组ID相同)。

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

  • 对于管理和配置

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

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

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

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

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

MirrorMaker 2.*和优点

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

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

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

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

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

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

  • 支持一个高级配置文件,用于指定多个群集和复制流,并与每个群集的低级别生产者/消费者属性进行比较 MirrorMaker 1.*处理。