摘要：使用，可以設置一個名為的系統，將一組可配置的主題從一個數據中心轉發到另一個數據中心。此外，在每個數據中心中有一些名為的程序實例。在每個數據中心中，選擇一個領導者，與其他數據中心的進行交流，以組織復制。

摘要: 每個公司都需要為所有重要系統制定災難恢復計劃。從單個進程到最大的分布式體系結構的小單元都是這樣。特別是對于數據庫，這通常涉及容錯，冗余，定期備份和應急計劃的混合。數據庫越大，制定好策略就越困難。 這篇文章概述了ArangoDB向多數據中心支持的第一個進化步驟--數據中心到數據中心的異步復制。

此功能允許您在兩個不同的數據中心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 的里程碑版。