每家公司都需要為所有重要系統(tǒng)制定災(zāi)難恢復(fù)計劃。從像在某個容器中運(yùn)行的單個進(jìn)程這樣的小單元到最大的分布式架構(gòu)都是如此。特別是對于數(shù)據(jù)庫，這通常涉及容錯、冗余、定期備份和應(yīng)急計劃的混合。數(shù)據(jù)存儲越大，制定好的策略就越困難。

因此，希望能夠在一個數(shù)據(jù)中心運(yùn)行分布式數(shù)據(jù)庫，并以某種方式將所有事務(wù)復(fù)制到另一個數(shù)據(jù)中心。通常，事務(wù)日志通過網(wǎng)絡(luò)傳送，以便在另一個數(shù)據(jù)中心的另一個相同系統(tǒng)中復(fù)制所有內(nèi)容。一些分布式數(shù)據(jù)存儲具有對多數(shù)據(jù)中心感知的內(nèi)置支持，并且可以以全自動方式在數(shù)據(jù)中心之間復(fù)制。

ArangoDB3.3通過引入多數(shù)據(jù)中心支持向前邁出了進(jìn)化的一步，即數(shù)據(jù)中心到數(shù)據(jù)中心的復(fù)制。我們的解決方案是異步的，并且可以擴(kuò)展到任意集群大小，前提是您的數(shù)據(jù)中心之間的網(wǎng)絡(luò)鏈接有足夠的帶寬。它是容錯的，沒有單點故障，并且包含許多用于在生產(chǎn)場景中監(jiān)控的指標(biāo)。

它能做什么

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

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

挑戰(zhàn)

在本節(jié)中，我們不想讓您厭煩技術(shù)細(xì)節(jié)，我們將在適當(dāng)?shù)臅r候發(fā)布一份白皮書。相反，我們想強(qiáng)調(diào)這種方法的挑戰(zhàn)，并概述我們?yōu)榭朔@些挑戰(zhàn)而采取的措施。

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

同時，ArangoDB集群是容錯的。例如，如果數(shù)據(jù)中心中的單個服務(wù)器發(fā)生故障，ArangoDB集群可以輕松容忍這種損失，并且假設(shè)用戶已將復(fù)制因子設(shè)置為至少2，既不會丟失任何數(shù)據(jù)，也不會損失可用性. 系統(tǒng)只需切換到使用另一臺服務(wù)器，重新分配數(shù)據(jù)并繼續(xù)前進(jìn)，而不會影響查詢性能。因此，任何適當(dāng)?shù)膹?fù)制解決方案都必須滿足集群A中的這些透明故障轉(zhuǎn)移。

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

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

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

怎么運(yùn)行的

在數(shù)據(jù)中心A中，ArangoDB集群A照常運(yùn)行，無需修改其代碼庫和API，并提供其通常的負(fù)載。同樣，在數(shù)據(jù)中心B中，第二個ArangoDB集群B已部署，但最初處于空閑狀態(tài)。

在這兩個數(shù)據(jù)中心中，我們部署了一個Kafka消息代理，這是一個標(biāo)準(zhǔn)的高性能和容錯隊列系統(tǒng)，能夠在其消息隊列中緩沖大量數(shù)據(jù)。單個隊列在Kafka中稱為“主題”。這些主題可能會從其他數(shù)據(jù)中心消費。Kafka有一定的保證，因此在出現(xiàn)網(wǎng)絡(luò)問題、個別中斷等情況時，不會丟失任何消息，并且遠(yuǎn)程數(shù)據(jù)中心將始終保持一致的狀態(tài)。

此外，在每個數(shù)據(jù)中心，都有幾個名為“ArangoDBSyncMaster”的程序?qū)嵗Ｔ诿總€數(shù)據(jù)中心，SyncMasters選舉一個領(lǐng)導(dǎo)者，該領(lǐng)導(dǎo)者與另一個數(shù)據(jù)中心的SyncMaster對話以組織復(fù)制。“組織”在這里意味著它計劃必須在兩個數(shù)據(jù)中心中執(zhí)行的單個任務(wù)以進(jìn)行復(fù)制。本質(zhì)上，必須復(fù)制元信息，例如存在哪些數(shù)據(jù)庫、集合和用戶，以及分片集合中的實際數(shù)據(jù)。

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

這些任務(wù)負(fù)責(zé)初始增量同步階段（運(yùn)行我們在ArangoDB中已有的現(xiàn)有分片同步協(xié)議），以及后期更新階段，其中對分片的所有更新都復(fù)制到另一個數(shù)據(jù)中心（使用WALtailing in數(shù)據(jù)中心A)。

數(shù)據(jù)流如下：它從ArangoDB集群的某個DBserver開始，到達(dá)數(shù)據(jù)中心A中的一個SyncWorker，然后進(jìn)入數(shù)據(jù)中心A中的Kafka。從那里它將被寫入它的數(shù)據(jù)中心B的SyncWorker使用進(jìn)入數(shù)據(jù)中心B中的協(xié)調(diào)器。顯然，有一些控制消息以相反的方向流動。這些控制消息將由數(shù)據(jù)中心A從數(shù)據(jù)中心B的Kafka服務(wù)器中獲取。

這對管理員來說意味著，在初始部署后，只需告訴數(shù)據(jù)中心B中的SyncMaster它應(yīng)該開始跟隨數(shù)據(jù)中心A中的集群A，就可以使用一個命令設(shè)置異步復(fù)制。從那時起，一切都是全自動的，所有數(shù)據(jù)庫、集合、用戶和權(quán)限都會自動復(fù)制到另一個數(shù)據(jù)中心。顯然，有監(jiān)控和配置工具，但本質(zhì)上就是這樣。

限制

這是邁向多數(shù)據(jù)中心意識的第一步，因此自然會受到限制。首先，復(fù)制是異步的，所以它總是落后于DatacenterA中的實際事件。通常情況下，連接性好，寫入速率小于跨數(shù)據(jù)中心鏈路的容量，這個延遲非常小. 然而，應(yīng)該注意，在復(fù)制突然停止并手動切換到集群B的情況下，一些最近寫入的更新可能會丟失。

整個設(shè)置是手動配置的，并在兩個數(shù)據(jù)中心之間工作。此階段不允許寫入副本集群。然而，一個副本集群可以同時是另一個數(shù)據(jù)中心的源，一個源集群可以有多個副本。也就是說，您可以形成數(shù)據(jù)中心樹。

最后，關(guān)閉復(fù)制并開始使用副本到目前為止是一項手動操作，需要管理員做出決定和采取行動。
責(zé)任編輯：彭菁