如何用MirrorMaker2实现Kafka集群跨DC灾备同步及故障切换？

选择MirrorMaker2(MM2)作为跨DC数据同步方案完全合理——它是Kafka官方原生的跨集群复制工具，天生适配这种主备源切换的场景，相比U replicator（第三方工具）或自定义Kafka Connect（开发维护成本高），MM2在兼容性、稳定性和运维成本上都更有优势。

以下是具体的实践建议和经验分享：

• 主备切换的自动化配置
  不要依赖手动切换源集群，建议基于MM2的多源复制能力搭建active-passive切换机制：

  1. 预先在MM2配置文件中同时配置KCL_1和KCL_2作为源集群，默认将KCL_1设为活跃源，KCL_2设为备用源。
  2. 编写监控脚本定期检查KCL_1的broker可用性（通过kafka-broker-api-versions.sh或JMX指标），当检测到集群不可用超过设定阈值（比如5分钟），自动修改MM2的动态配置（利用Kafka的configs.sh工具），将活跃源切换为KCL_2。
  3. 配置offset.sync.topic确保切换后，北DC目标topic的偏移量与备用源KCL_2的对应偏移量对齐，避免数据重复或丢失。

• 数据一致性保障
  由于东DC和西DC互为备份，需先确保两集群的topic数据完全同步（建议东/西DC之间也用MM2做双向镜像），这样切换到KCL_2后，北DC能获取到与KCL_1无差异的数据流：

  • 开启MM2的exactly-once复制模式（需源/目标集群支持事务），严格保证数据的一次性交付。
  • 定期校验东/西DC同topic的偏移量，确保备份的一致性，避免切换后出现数据断层。

• 监控与告警体系
  搭建全方位监控是保障切换可靠性的核心：

  • 监控MM2进程状态、复制延迟（通过mm2-offset-syncs主题的偏移量差值判断）、源集群的broker在线状态。
  • 设置告警规则：KCL_1离线超过阈值、MM2复制延迟超过预设值（比如10分钟）、北DC目标topic无新消息流入。
  • 利用Prometheus+Grafana可视化监控指标，快速定位问题。

• 故障切换测试
  上线前必须完成多场景测试：

  • 模拟KCL_1完全宕机、部分broker故障、网络分区等场景，验证切换流程的自动化程度和数据连续性。
  • 测试切换回KCL_1的场景，确保恢复后能无缝切回，且无数据冲突。

• 配置优化

  • 调整MM2消费者和生产者参数：增大producer.batch.size、调整consumer.fetch.min.bytes，优化跨DC带宽利用率，减少小批量传输带来的延迟。
  • 部署多个MM2实例（集群模式），避免单点故障，利用Kafka消费者组实现负载均衡。
  • 北DC目标topic设置足够的replication.factor（至少3），保证数据本地可靠性。

内容的提问来源于stack exchange，提问作者brij singh