自建 Kafka 遷移到阿里雲自建 Kafka 方案 - Migration Hub

一、適用情境

本方案適用於與它雲廠商或 IDC 自建 Kafka 遷移至阿里雲自建 Kafka 情境。

遷移類型適用於：中繼資料遷移；

二、遷移相關工具介紹

1、MirrorMaker

MirrorMaker 是 Apache Kafka 提供的用於跨叢集資料複製的工具，支援兩種版本：

MirrorMaker 1：通過 kafka-mirror-maker.sh 指令碼實現，僅支援訊息遷移，不支援中繼資料同步。
MirrorMaker 2：通過 connect-mirror-maker.sh 指令碼實現，支援中繼資料遷移和訊息遷移，需依賴 Kafka Connect 架構。

需根據源端 Kafka 版本判斷使用哪種 MirrorMaker：若 kafka/bin/ 目錄下存在 connect-mirror-maker.sh，則為 MirrorMaker 2；否則為 MirrorMaker 1。

三、遷移方案

1、遷移整體流程

執行個體建立：在阿里雲 ECS 上部署自建 Kafka 叢集，完成基礎環境配置。
資料移轉：
- 中繼資料遷移：通過 MirrorMaker 2 同步 Topic 配置、分區數、副本數、ACL 許可權等中繼資料資訊。
資料校正：校正 Topic 數量、分區數、訊息數量、訊息內容一致性。

2、資料移轉方案

2.1、使用 MirrorMaker

遷移原理：

通過 MirrorMaker 的 Consumer 和 Producer 模組，從源 Kafka 叢集拉取訊息並寫入目標 Kafka 叢集，實現資料同步。

前置條件：

源端 Kafka 叢集可訪問（需開放網路連接埠）。
目標端 Kafka 叢集已部署並運行正常。
確保 MirrorMaker 版本與源端 Kafka 版本相容。

風險及注意項：

資料移轉過程中需監控網路頻寬、磁碟 I/O 及 Kafka 叢集負載。
若源端 Kafka 存在未提交的事務訊息，需確保事務一致性。

方案優勢：

支援全量與增量遷移，滿足大規模資料同步需求。
通過配置靈活控制遷移範圍（如指定 Topic 白名單）。

3、資料校正方案

3.1、中繼資料校正

使用 kafka-topics.sh --describe 檢查目的地組群的 Topic 配置是否與源端一致。
對比分區數、副本數、ACL 許可權等中繼資料資訊。

五、實施遷移過程

1、使用阿里雲 RocketMQ 控制台遷移工具進行中繼資料/訊息遷移

遷移實施採用 MirrorMaker 進行，該工具在 bin 目錄下：kafka-mirror-maker.sh

第一步：配置 consumer 和 provider

遷移的重點在於配置 MirrorMaker 的 Consumer 和 Producer，即 config 檔案夾下的consumer.properties、producer.properties 檔案。

consumer.properties檔案配置如下：

# 注意這裡配置的是源端的地址
bootstrap.servers=172.20.77.74:9092 

# consumer group id
group.id=migration-group

auto.offset.reset=earliest

producer.properties 配置如下：

# format: host1:port1,host2:port2 ...
# 注意這裡配置的是目標端的地址
bootstrap.servers=172.20.77.91:9092

第二步：執行中繼資料遷移

配置完成後，執行遷移命令，其中：

--whiteList ：需要遷移的topic列表，以逗號分隔

./kafka-mirror-maker.sh --consumer.config ../config/consumer.properties --producer.config ../config/producer.properties --whitelist="migration-to-aliyun"

第三步：監控遷移狀態

查看 MirrorMaker 日誌（logs/mirror-maker.log）確認無錯誤。
通過 kafka-topics.sh --list 驗證目的地組群 Topic 是否建立成功。

六、資料校正過程

1、中繼資料校正

使用 kafka-topics.sh --describe --zookeeper <zk_host> 對比源端與目標端的 Topic 配置。驗證 ACL 許可權是否同步（如 kafka-acls.sh 命令）。

七、遷移注意事項

1、版本相容性：確保源端與目標端 Kafka 版本相容，避免因協議差異導致遷移失敗。

2、網路連通性：遷移期間需保持源端與目標端網路穩定，避免中斷。

3、資料一致性：遷移過程中需避免源端資料變更，或通過增量同步處理保證一致性。

4、資源預留：遷移期間需預留足夠的 CPU、記憶體和頻寬資源，防止效能瓶頸。

5、復原計劃：制定遷移失敗時的復原方案，如保留源端資料並快速恢複業務。