MirrorMaker 2：跨集群复制怎么做

验证：两个真实独立的集群，一份mm2.properties配置复制关系

配置 · mm2.properties clusters = A, B A.bootstrap.servers = localhost:19092 B.bootstrap.servers = localhost:19192 A->B.enabled = true A->B.topics = mm2-source-topic B->A.enabled = false

命令 · shell $ connect-mirror-maker.sh mm2.properties

验证：cluster B上真实自动多出了带前缀的topic，历史数据也真实全部复制过去了

真实实测 · 本机执行输出

$ kafka-topics.sh --bootstrap-server localhost:19192 --list
A.checkpoints.internal
A.heartbeats
A.mm2-source-topic     ← 真实新增，源集群名A被当作前缀
mm2-configs.A.internal
mm2-offsets.A.internal
mm2-status.A.internal

真实cluster B上A.mm2-source-topic的内容(共50条):
['clusterA-msg-0', 'clusterA-msg-1', 'clusterA-msg-2', 'clusterA-msg-3', 'clusterA-msg-4', ...]

MirrorMaker2真实用源集群别名.原topic名这个命名规则(A.mm2-source-topic)，避免复制过来的topic跟目标集群本地同名topic真实发生冲突。真实自动创建的一堆mm2-*.internaltopic，是MM2自己用来记录复制进度、心跳、配置的内部状态，不是业务数据。

验证：MM2运行期间，新写的数据真实持续同步过去

命令 · python p.produce("mm2-source-topic", value="live-msg-0" ~ "live-msg-9") # 真实往cluster A写10条

真实实测 · 本机执行输出(3秒后)

真实3秒后cluster B看到的新增内容:
['live-msg-0', 'live-msg-1', ..., 'live-msg-9']

MM2真实的工作原理并不神秘——它本质上就是一个真实的Kafka Connect Source Connector，从cluster A当consumer读数据，从cluster B当producer写数据，中间真实经过Kafka Connect标准的任务分发和offset管理框架，跟本系列《Kafka Connect》那篇的FileStreamSource做的事情，真实是同一套底层机制，只是读写两端都换成了Kafka集群而不是本地文件。这也是为什么MM2真实是异步复制：produce到cluster A立刻算成功，之后MM2才把它读出来、写到cluster B，这个延迟窗口(本文观测到约3秒)真实意味着任何时刻cluster A有数据、cluster B还没有，是MirrorMaker2设计上就存在的正常现象，不是bug。

分步演示：一次真实的跨集群复制全过程

每一步都是本文上面用真实两个独立Kafka集群跑出来的原始结果。

跨集群复制本质上是一个真实的Kafka Connect任务

这一步新验证的状态

参考与说明

数据来自本机两个真实独立的Kafka 4.3.1集群：cluster A(3节点，本系列全程使用的集群)和真实新起的cluster B(单节点)，用connect-mirror-maker.sh + mm2.properties配置单向复制。
和《Kafka Connect》一起看：MM2真实底层复用的就是Kafka Connect的Source Connector框架。
没有验证：双向复制(A->B和B->A同时开启)时真实的循环复制防护机制；真实跨机房场景下的网络延迟对复制窗口的影响(本机是loopback网络)。

下一篇 · KAFKA 内部原理 78

多机房 Kafka：跨地域复制和故障切换