了解策略和流程，以及一些最佳實踐，讓任何大規模、關鍵任務的 Cassandra 和 Kafka 遷移更加順利。

譯自How We Completed a Massive Kafka and Cassandra Migration，作者 Ben Slater。

無論遷移規模如何，任何數據層遷移都需要進行仔細的規劃和執行。話雖如此，我們最近完成的可能是迄今為止執行過的最大規模的Apache Cassandra和Apache Kafka遷移（吉尼斯世界紀錄尚未對此進行統計……）。

在我看來，這是一個特別有趣的用例，它可以在沒有停機時間的情況下實現相當復雜的技術壯舉（并且僅使用 Cassandra 和 Kafka 的完全開源版本——這里沒有開放核心）。下面，我將分享所使用的策略和流程，以及一些最佳實踐，這些實踐將有助于使任何大規模、關鍵任務的 Cassandra 和 Kafka 遷移更加順利。

管理大規模遷移

讓我們了解一下這次遷移的規模。這家企業的開源Cassandra 部署包括 58 個集群和 1,079 個節點，其中包括 17 種不同的節點大小，分布在AWS和Kafka 前端上，該公司使用了 154 個集群和 1,050 個節點，共有 21 種節點大小，同樣分布在這兩個云提供商和六個區域中。正如你所想象的，進行遷移需要大量的時間和精力。時間表要求準備九個月，然后是八個月的謹慎生產遷移。

與任何遷移一樣，強大的項目管理和治理至關重要。如果這一步出了問題，你以后會遇到麻煩。我們根據項目管理方法為一些關鍵角色分配了具體職責，包括一名總體項目經理、一名 Cassandra 遷移項目經理和一名 Kafka 遷移項目經理、每項的技術負責人以及一名關鍵產品經理。這個團隊迅速建立了密切的協作和與企業的清晰溝通，這是獲得積極項目成果的另一種行之有效的方法。

在項目的初始階段，這種密切聯系證明了它的價值，因為我們與企業的架構、安全和合規團隊同步工作，以滿足他們在這些領域的嚴格要求。這意味著確保遷移的目標環境具有入侵檢測、訪問日志記錄、審計日志、強化操作系統以及帳戶級選擇加入，以自動配置具有日志傳輸和其他控制的新集群。我們還啟用了自定義 Kafka Connect 連接器的加載過程，以使用實例角色而不是訪問密鑰進行 Amazon S3 訪問，并改進了用于配置單點登錄 (SSO) 訪問的 SCIM（跨域身份管理系統）API。

在此準備階段，我們還認識到并采取了優化遷移集群的架構契合度的機會。由于企業的架構在 Kafka 集群級別之上提供了高可用性，因此我們使用 RF2（復制因子 2）來支持在兩個可用性區域中運行的 Kafka 集群。我們還準備通過利用最新的 AWS 和 GCP 節點類型來優化成本。

Kafka 遷移

“流出”方法是 Kafka 遷移的第一個想法：只需將 Kafka 消費者指向源集群和目標集群，將生產者切換為僅向目標集群發送消息，等到從源讀取所有消息，然后瞧。限制在于流出不會保留消息順序，這是許多 Kafka 用例（包括此用例）必不可少的。

MirrorMaker2為 Kafka 遷移提供了另一個強大的選擇，但是其高度的消費者/生產者應用程序依賴性意味著它不適合這里。

“共享集群”方法——將源集群和目標集群作為單個集群運行——成為剩下的最佳選擇。我們繼續為每個集群創建詳細的變更計劃，始終牢記回滾啟用。高級步驟從配置目標集群開始，更新配置以匹配源，并將網絡環境與源集群加入虛擬私有云對等互連。然后，我們在目標中以觀察者模式啟動Apache ZooKeeper，以及目標 Kafka 代理。

接下來，我們使用 Kafka 分區重新分配來移動數據。其中包括增加復制因子和跨目標和源代理的復制，將首選領導交換為目標代理，然后減少復制因子以移除源代理副本。通過將目標代理重新配置為其初始聯系點，然后移除舊代理，從而完成流程。

源環境額外帶來了一些皺褶，我們在遷移期間已將其熨平。例如，它跨多個集群共享一個 ZooKeeper 實例，導致我們仔細重新配置和清理每個目標 ZooKeeper 中其他集群的數據。我們還擴展了目標配置以支持企業的特定端口偵聽器映射，避免了主要的重新配置工作。

Cassandra 遷移

零停機 Cassandra 遷移最常見的方法是向現有集群添加數據中心。我們還使用并推薦我們的 Instaclustr Minotaur 一致重建工具（在 GitHub 上提供）。此開源解決方案解決了源集群中缺少數據副本可能導致重建過程從同一節點復制多個副本的問題，從而導致目標副本減少。Minotaur 確保目標集群至少具有與源集群一樣多的副本，并且可以將任何需要的修復推遲到遷移之后。

當我們遇到具有高度不一致性的集群時，對這次遷移使用此方法特別有價值。在一個案例中，集群在遷移后需要兩個半月的修復。另一組集群由于在流式傳輸期間架構更改時 Cassandra 丟棄臨時數據，因此每兩到三個小時定期丟棄表。我們首先嘗試在節點重建期間手動暫停表丟棄，但發現該方法不可持續。最后，我們使用我們的供應 API 檢測節點狀態并在必要時自動暫停表丟棄。

重大挑戰，巨大成功

最終，（也許）有史以來最大規模的 Cassandra 和 Kafka 遷移按計劃完成，且幾乎沒有出現問題。我將這一積極成果歸功于所有參與者密切合作、周密規劃和采用的戰略最佳實踐，并建議任何參與類似的大型復雜遷移的人員應用這些相同技術。