迁移到 Amazon MSK 集群 - Amazon Managed Streaming for Apache Kafka
MirrorMaker 1.0 最佳实践 MirrorMaker 2. 的优点 *
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

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

迁移到 Amazon MSK 集群

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

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

  1. 创建目标 MSK 集群

  2. MirrorMaker 从目标集群所在的同一 Ama EC2 zon VPC 中的 Amazon VPC 中的 Amazon VPC。

  3. 检查延 MirrorMaker 迟。

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

  5. 关闭 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

  • 为避免数据丢失，请在源端关闭 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 实例。

  • 对于管理和配置

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

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

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

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

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

MirrorMaker 2. 的优点 *

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

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

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

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

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

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

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