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

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

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

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

管理大規(guī)模遷移

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

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

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

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

Kafka 遷移

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

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

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

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

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

Cassandra 遷移

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

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

重大挑戰(zhàn)，巨大成功

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