摘要：使用，可以設(shè)置一個名為的系統(tǒng)，將一組可配置的主題從一個數(shù)據(jù)中心轉(zhuǎn)發(fā)到另一個數(shù)據(jù)中心。此外，在每個數(shù)據(jù)中心中有一些名為的程序?qū)嵗Ｔ诿總€數(shù)據(jù)中心中，選擇一個領(lǐng)導(dǎo)者，與其他數(shù)據(jù)中心的進行交流，以組織復(fù)制。

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

此功能允許您在兩個不同的數(shù)據(jù)中心A和B中運行兩個ArangoDB 群集，并設(shè)置從A到B的異步復(fù)制。這意味著數(shù)據(jù)中心A中的群集A可以照常用于讀取和寫入操作以及所有更改數(shù)據(jù)通過網(wǎng)絡(luò)復(fù)制到數(shù)據(jù)中心B中的另一個集群B。復(fù)制是異步的，也就是說，更改出現(xiàn)在短暫的延遲之后，通常在幾秒鐘內(nèi)。(閱讀更多關(guān)于ArangoDB集群架構(gòu)）

在數(shù)據(jù)中心A發(fā)生災(zāi)難的情況下，如網(wǎng)絡(luò)連接完全丟失，可以快速停止復(fù)制，并開始使用數(shù)據(jù)中心B中的群集B作為群集A的替代品。之后，當災(zāi)難結(jié)束時，可以或者使用集群A作為群集B的異步副本，或者切換回A并繼續(xù)復(fù)制到群集A。

單個ArangoDB集群是具有良好的水平可擴展性的分布式系統(tǒng)。數(shù)據(jù)容量和查詢性能（讀寫）都與使用的服務(wù)器數(shù)量呈線性關(guān)系。自動分片導(dǎo)致數(shù)據(jù)的實際更改同時發(fā)生在所有服務(wù)器的整個地方。特別是，這意味著設(shè)計 - 沒有一個地方確定所有更改的總順序。也就是說，我們正在處理同時發(fā)生大量數(shù)據(jù)更新的分布式混亂。變化率可能會有很大差異，我們必須處理大量的寫入突發(fā)。

同時，ArangoDB集群是容錯的。例如，如果數(shù)據(jù)中心中的單個服務(wù)器出現(xiàn)故障，則ArangoDB群集可以容易地容忍這種損失，并假定用戶將復(fù)制因子設(shè)置為至少為2 - 既沒有丟失任何數(shù)據(jù)，也沒有丟失可用性。系統(tǒng)簡單地切換到使用另一臺服務(wù)器，重新分配數(shù)據(jù)并移動，而不影響查詢性能。因此，任何正確的復(fù)制解決方案都必須滿足群集A中的這些透明故障切換。

另一方面，安全問題和防火墻維護意味著我們不能輕易地在許多不同的進程與其他數(shù)據(jù)中心中的許多不同進程進行交談，但同樣，我們也不能輕易地通過兩個進程之間的單個網(wǎng)絡(luò)連接的瓶頸來移動所有更新在不同的數(shù)據(jù)中心。

顯然，整個復(fù)制系統(tǒng)是分布式系統(tǒng)的分布式系統(tǒng)，因此必須具有可擴展性和容錯性，而無需單點故障。

所有這些挑戰(zhàn)決定了我們的解決方案的設(shè)計。

在數(shù)據(jù)中心A中，ArangoDB集群A像往常一樣運行，不對其代碼庫和API進行任何修改，并提供其通常的負載。同樣，在數(shù)據(jù)中心B中，部署了第二個ArangoDB群集B，但最初空閑。

在兩個數(shù)據(jù)中心中，我們部署了一個Kafka 消息代理，它是一種標準的高性能和容錯排隊系統(tǒng)，能夠緩沖其消息隊列中的大量數(shù)據(jù)。個人隊列在卡夫卡被稱為“主題”。使用Kafka，可以設(shè)置一個名為“MirrorMaker”的系統(tǒng)，將一組可配置的Kafka 主題從一個數(shù)據(jù)中心轉(zhuǎn)發(fā)到另一個數(shù)據(jù)中心。寫入其中一個主題的所有內(nèi)容最終出現(xiàn)在另一個數(shù)據(jù)中心的Kafka 中的相應(yīng)主題中。這是我們在數(shù)據(jù)中心之間移動消息和數(shù)據(jù)的主要手段。

此外，在每個數(shù)據(jù)中心中有一些名為“ArangoDB SyncMaster”的程序?qū)嵗?。在每個數(shù)據(jù)中心中，SyncMasters選擇一個領(lǐng)導(dǎo)者，與其他數(shù)據(jù)中心的SyncMaster進行交流，以組織復(fù)制。 “組織”在這里表示，它計劃必須在兩個數(shù)據(jù)中心執(zhí)行的各個任務(wù)才能進行復(fù)制。實質(zhì)上，必須復(fù)制數(shù)據(jù)庫，集合和用戶所在的元信息以及分片集合中的實際數(shù)據(jù)。

在每個數(shù)據(jù)中心，領(lǐng)先的SyncMaster指揮執(zhí)行實際復(fù)制任務(wù)的一小部分SyncWorkers。例如，對于集合的每個分片，數(shù)據(jù)中心A中都有“發(fā)送分片”任務(wù)以及數(shù)據(jù)中心B中的“接收分頁”任務(wù)，并且所有這些分片由SyncMaster分配給某些SyncWorker。

這些任務(wù)負責初始增量同步階段（運行ArangoDB中已有的現(xiàn)有分片同步協(xié)議）以及后期更新階段，其中分片的所有更新都會在其他數(shù)據(jù)中心中復(fù)制（使用WAL拖尾數(shù)據(jù)中心A）。

數(shù)據(jù)流如下：它從ArangoDB集群的一些DBserver開始，轉(zhuǎn)到Datacenter A中的一個SyncWorkers，然后進入Datacenter A中的Kafka。從那里，MirrorMaker將其移動到Datacenter B，在那里它被一些SyncWorker并最終寫入數(shù)據(jù)中心B的協(xié)調(diào)器。顯然，有一些控制消息在相反的方向流動，但是它們也使用兩個Kafkas和MirrorMaker傳輸。

這對管理員來說，這意味著在初始部署之后，可以通過一個命令設(shè)置異步復(fù)制，只需告訴Datacenter B中的SyncMaster應(yīng)該開始跟蹤數(shù)據(jù)中心A中的集群A.所有從此開始的都是全自動的，所有數(shù)據(jù)庫，集合，用戶和權(quán)限都將自動復(fù)制到其他數(shù)據(jù)中心。顯然，有監(jiān)控和配置設(shè)施，但基本上是這樣的。

這是邁向多數(shù)據(jù)中心意識的第一步，因此自然會帶來局限性。首先，復(fù)制是異步的，所以它總是落后于Datacenter A 中的實際事件。通常，連接性好，寫入速度小于跨數(shù)據(jù)中心鏈路的容量，這種延遲非常小。然而，應(yīng)該意識到，在突然停止復(fù)制和手動切換到群集B的情況下，最近可能會寫入的更新可能會丟失。整個設(shè)置是手動配置的，并且在兩個數(shù)據(jù)中心之間工作。在此階段不允許寫入復(fù)制集群。然而，復(fù)制集群可以同時成為另一個數(shù)據(jù)中心的源，源集群可以有多個副本。也就是說，您可以形成數(shù)據(jù)中心的樹。最后，關(guān)閉復(fù)制并開始使用副本仍舊需要管理員手動做出操作。

到目前為止，我們有一般的安裝說明，以及RedHat Enterprise 7 和Centos 7 的具體部署說明和腳本（請參閱此處，包括README.me和說明）。請注意，此功能僅包含在ArangoDB Enterprise 版本中，并且我們發(fā)布的RPM包包含所有必需的部分。

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