怎麼用Kafka 實現數據中心到數據中心的複製？

它能作什麼？

此功能容許您在兩個不一樣的數據中心A和B中運行兩個ArangoDB 羣集，並設置從A到B的異步複製。這意味着數據中心A中的羣集A能夠照經常使用於讀取和寫入操做以及全部更改數據經過網絡複製到數據中心B中的另外一個集羣B。複製是異步的，也就是說，更改出如今短暫的延遲以後，一般在幾秒鐘內。(閱讀更多關於ArangoDB集羣架構）

在數據中心A發生災難的狀況下，如網絡鏈接徹底丟失，能夠快速中止複製，並開始使用數據中心B中的羣集B做爲羣集A的替代品。以後，當災難結束時，能夠或者使用集羣A做爲羣集B的異步副本，或者切換回A並繼續複製到羣集A。

挑戰 ？

單個ArangoDB集羣是具備良好的水平可擴展性的分佈式系統。數據容量和查詢性能（讀寫）都與使用的服務器數量呈線性關係。自動分片致使數據的實際更改同時發生在全部服務器的整個地方。特別是，這意味着設計 - 沒有一個地方肯定全部更改的總順序。也就是說，咱們正在處理同時發生大量數據更新的分佈式混亂。變化率可能會有很大差別，咱們必須處理大量的寫入突發。

同時，ArangoDB集羣是容錯的。例如，若是數據中心中的單個服務器出現故障，則ArangoDB羣集能夠容易地容忍這種損失，並假定用戶將複製因子設置爲至少爲2  - 既沒有丟失任何數據，也沒有丟失可用性。系統簡單地切換到使用另外一臺服務器，從新分配數據並移動，而不影響查詢性能。所以，任何正確的複製解決方案都必須知足羣集A中的這些透明故障切換。

另外一方面，安全問題和防火牆維護意味着咱們不能輕易地在許多不一樣的進程與其餘數據中心中的許多不一樣進程進行交談，但一樣，咱們也不能輕易地經過兩個進程之間的單個網絡鏈接的瓶頸來移動全部更新在不一樣的數據中心。

顯然，整個複製系統是分佈式系統的分佈式系統，所以必須具備可擴展性和容錯性，而無需單點故障。

全部這些挑戰決定了咱們的解決方案的設計。

 

怎麼運行 ？

在數據中心A中，ArangoDB集羣A像往常同樣運行，不對其代碼庫和API進行任何修改，並提供其一般的負載。一樣，在數據中心B中，部署了第二個ArangoDB羣集B，但最初空閒。

在兩個數據中心中，咱們部署了一個Kafka 消息代理，它是一種標準的高性能和容錯排隊系統，可以緩衝其消息隊列中的大量數據。我的隊列在卡夫卡被稱爲「主題」。使用Kafka，能夠設置一個名爲「MirrorMaker」的系統，將一組可配置的Kafka 主題從一個數據中心轉發到另外一個數據中心。寫入其中一個主題的全部內容最終出如今另外一個數據中心的Kafka 中的相應主題中。這是咱們在數據中心之間移動消息和數據的主要手段。

此外，在每一個數據中心中有一些名爲「ArangoDB SyncMaster」的程序實例。在每一個數據中心中，SyncMasters選擇一個領導者，與其餘數據中心的SyncMaster進行交流，以組織複製。 「組織」在這裏表示，它計劃必須在兩個數據中心執行的各個任務才能進行復制。實質上，必須複製數據庫，集合和用戶所在的元信息以及分片集合中的實際數據。

在每一個數據中心，領先的SyncMaster指揮執行實際複製任務的一小部分SyncWorkers。例如，對於集合的每一個分片，數據中心A中都有「發送分片」任務以及數據中心B中的「接收分頁」任務，而且全部這些分片由SyncMaster分配給某些SyncWorker。

這些任務負責初始增量同步階段（運行ArangoDB中已有的現有分片同步協議）以及後期更新階段，其中分片的全部更新都會在其餘數據中心中複製（使用WAL拖尾數據中心A）。

數據流以下：它從ArangoDB集羣的一些DBserver開始，轉到Datacenter A中的一個SyncWorkers，而後進入Datacenter A中的Kafka。從那裏，MirrorMaker將其移動到Datacenter B，在那裏它被一些SyncWorker並最終寫入數據中心B的協調器。顯然，有一些控制消息在相反的方向流動，可是它們也使用兩個Kafkas和MirrorMaker傳輸。

這對管理員來講，這意味着在初始部署以後，能夠經過一個命令設置異步複製，只需告訴Datacenter B中的SyncMaster應該開始跟蹤數據中心A中的集羣A.全部今後開始的都是全自動的，全部數據庫，集合，用戶和權限都將自動複製到其餘數據中心。顯然，有監控和配置設施，但基本上是這樣的。

 

限制 ？

這是邁向多數據中心意識的第一步，所以天然會帶來侷限性。首先，複製是異步的，因此它老是落後於Datacenter A 中的實際事件。一般，鏈接性好，寫入速度小於跨數據中心鏈路的容量，這種延遲很是小。然而，應該意識到，在忽然中止複製和手動切換到羣集B的狀況下，最近可能會寫入的更新可能會丟失。整個設置是手動配置的，而且在兩個數據中心之間工做。在此階段不容許寫入複製集羣。然而，複製集羣能夠同時成爲另外一個數據中心的源，源集羣能夠有多個副本。也就是說，您能夠造成數據中心的樹。最後，關閉複製並開始使用副本仍舊須要管理員手動作出操做。

 

如何設置 ？

到目前爲止，咱們有通常的安裝說明，以及RedHat Enterprise 7 和Centos 7 的具體部署說明和腳本（請參閱此處，包括README.me和說明）。請注意，此功能僅包含在ArangoDB Enterprise 版本中，而且咱們發佈的RPM包包含全部必需的部分。

下載即將到來的ArangoDB 3.3 的里程碑版。