本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
使用ApacheKafka迁移群集 MirrorMaker
您可以使用镜像或迁移群集 MirrorMaker,它是ApacheKafka的一部分。例如,可以使用它将 Apache Kafka 群集迁移到 Amazon MSK
或从一个 MSK 集群迁移到另一个 MSK 集群。有关如何使用的信息 MirrorMaker,请参阅 在群集之间镜像数据
使用 MirrorMaker 迁移到 MSK 集群
-
创建目标 MSK 集群
-
开始 MirrorMaker 从 Amazon EC2 实例 Amazon VPC 作为目标群集。
-
检查 MirrorMaker 滞后。
-
之后 MirrorMaker 使用MSK群集bootstrapbroker,将生产者和消费者重新引导到新群集。
-
关闭 MirrorMaker.
将 Apache Kafka 集群迁移到 Amazon MSK
假设您有一个名为ApacheKafka的群集 CLUSTER_ONPREM
。该群集将填充主题和数据。如果要将该集群迁移到新创建的名为 CLUSTER_AWSMSK
的 Amazon MSK 集群,此过程将提供您需要执行的步骤的高级视图。
将现有的 Apache Kafka 集群迁移到 Amazon MSK
-
在
CLUSTER_AWSMSK
中,创建要迁移的所有主题。无法使用 MirrorMaker ,因为它不会自动创建您要以正确的复制级别迁移的主题。您可以在以下位置创建主题: Amazon MSK 具有相同的复制因子和分区数量
CLUSTER_ONPREM
。您还可以创建具有不同复制因子和分区数量的主题。 -
开始 MirrorMaker 从具有读取访问权限的实例
CLUSTER_ONPREM
并写入访问CLUSTER_AWSMSK
. -
运行以下命令以镜像所有主题:
./bin/kafka-mirror-maker.sh --consumer.config config/mirrormaker-consumer.properties --producer.config config/mirrormaker-producer.properties --whitelist '.*'
在此命令中,
config/mirrormaker-consumer.properties
指向中的bootstrapbrokerCLUSTER_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
. -
保留 MirrorMaker 在后台运行,并继续使用
CLUSTER_ONPREM
。 MirrorMaker 会镜像所有新数据。 -
通过检查每个主题的最后一个偏移量与当前偏移量之间的滞后时间,检查镜像进度, MirrorMaker 正在消耗。
请记住 MirrorMaker 只是使用消费者和生产商。因此,您可以使用
kafka-consumer-groups.sh
工具检查滞后。要查找使用器组名称,请在mirrormaker-consumer.properties
文件中查找group.id
,然后使用其值。如果文件中没有此类密钥,您可以创建它。例如,设置group.id=mirrormaker-consumer-group
。 -
之后 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.*处理。