在 Debian 上实施 Kafka 数据迁移的实用方案
一、迁移方案速览与选择
- 单写双消费：先迁移 Topic 元数据，原有消费者不动；新起一组消费者连到新集群；等所有消费者都监听新集群后，将生产切换到新集群；旧消费者继续消费旧集群直至清空再下线。优点是流程清晰、无积压；缺点是需要额外起一套消费者。适合对可用性要求高、可短期双写的场景。
- 单写单消费：先迁移元数据，直接把生产切到新集群；旧消费者继续消费旧集群直至清空，再把消费者切到新集群。优点是简单；缺点是切换后到消费者切换前，新集群会短暂堆积。适合容忍短暂堆积的场景。
- MirrorMaker 2 复制：用 MirrorMaker 2 持续镜像主题数据（含历史），再按序切换生产者和消费者。优点是能覆盖存量+增量、切换可控；缺点是消费者切到新集群后通常需从新集群的起始位点重放，需业务具备幂等。适合需要“历史+增量”一并迁移的场景。
- 仅迁移 Topic 元数据：当只需“空 Topic”迁移（无历史数据）时，先在新集群批量创建同名 Topic（分区数、副本数、清理策略一致），再切换生产/消费。适合全新业务或重建集群的场景。
二、在 Debian 上的落地步骤
- 前置准备
- 确保网络互通（同 VPC 或打通专线/公网）、安全组放通 9092/9093 等端口；新集群的 Topic 配置（名称、分区数、副本数、retention.ms、cleanup.policy）与原集群一致；ACL/SASL 等认证方式一致；容量评估（如目标为 3 副本，存储建议≥原单副本的 3 倍）。
- 元数据迁移
- 使用 Kafka 命令行导出/导入 Topic 配置（示例）：
- 导出：/opt/kafka/bin/kafka-topics.sh --bootstrap-server <源地址:9092> --describe --topic > topic_desc.txt
- 在新集群按导出的分区与副本数创建空 Topic（或使用脚本批量创建）。
- 数据复制
- 使用 MirrorMaker 2（推荐，Debian 上以服务或容器运行均可）：
- 配置源/目标连接（security.protocol、sasl.mechanism、jaas 等），开启自动 topic 创建与复制一致性校验；
- 启动镜像任务，观察复制延迟与滞后（通过 JMX 或监控面板），待滞后接近 0 且关键 Topic 复制一致后进入切换窗口。
- 切换与验证
- 按所选方案切换生产（单写双消费/单写单消费），再切换消费；切换后核对位点（group offsets）、监控积压（lag）、错误率与端到端时延；验证消息顺序、幂等与业务正确性。
三、常见场景与推荐路径
- 跨云/上云迁移：优先用云厂商提供的 Kafka 连接器 或 MirrorMaker 完成数据同步，再按“先消费后生产”或“双写”策略切换，兼顾存量与增量。
- 同机房/同网段重建集群：优先 MirrorMaker 2 做全量+增量镜像，切换前在窗口期做最终一致性校验，切换后按需回放或重置位点。
- 仅需空 Topic 迁移：直接在新集群批量创建同名 Topic 并复制配置，无需数据复制步骤。
四、关键注意事项
- 顺序与幂等：跨集群切换可能引入乱序或重复；对顺序敏感的业务优先“先迁生产、后迁消费”，对重复敏感的业务需开启幂等生产者（enable.idempotence=true）与业务端去重。
- 位点与回放：MirrorMaker 2 切换后消费者通常从新集群的起始位点消费，需评估重放成本与存储压力；必要时在切换前设置保存点/位点策略。
- 监控与告警：全程关注 Lag、生产/消费错误率、复制延迟、磁盘/带宽；在切换窗口设置灰度与回滚预案。
- ACL/SASL/SSL：保持认证与授权配置一致，避免因权限问题导致镜像或切换失败。
- 存储与副本：目标集群若为 3 副本，需预留足够磁盘空间（建议≥原单副本的 3 倍）。