工作原理

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

在這兩個數(shù)據(jù)中心中，我們都部署了Kafka消息代理，這是一個標準的高性能容錯排隊系統(tǒng)，能夠在其消息隊列中緩沖大量數(shù)據(jù)。在卡夫卡中，單個隊列被稱為“主題”。這些主題可以從其他數(shù)據(jù)中心使用?？ǚ蚩ㄓ幸欢ǖ谋ＷC，因此在網(wǎng)絡問題、個別中斷等情況下，不會丟失任何消息，遠程數(shù)據(jù)中心始終保持一致狀態(tài)。

此外，在每個數(shù)據(jù)中心中，都有幾個名為“ArangoDBSyncMaster”的程序?qū)嵗Ｔ诿總€數(shù)據(jù)中心，同步主機選擇一個負責人，負責人與另一個數(shù)據(jù)中心的同步主機對話，以組織復制?！敖M織”在這里意味著它計劃了必須在兩個數(shù)據(jù)中心中執(zhí)行的單個任務，以使復制得以進行。從本質(zhì)上講，我們必須復制元信息，如數(shù)據(jù)庫、集合和用戶的存在，以及切分集合中的實際數(shù)據(jù)。

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

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

數(shù)據(jù)流如下：它從ArangoDB集群的某個數(shù)據(jù)庫服務器開始，到達數(shù)據(jù)中心A中的一個SyncWorker，然后進入數(shù)據(jù)中心A的Kafka。從那里，它將被數(shù)據(jù)中心B的SyncWorkers消耗，后者將其寫入數(shù)據(jù)中心B中的協(xié)調(diào)器。顯然，有一些控制消息朝相反的方向流動。這些控制消息將由數(shù)據(jù)中心A從數(shù)據(jù)中心B中的Kafka服務器中提取。

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

局限性

這是實現(xiàn)多數(shù)據(jù)中心意識的第一步，因此自然會有局限性。首先，復制是異步的，因此它總是落后于數(shù)據(jù)中心a中的實際事件。通常情況下，由于良好的連接性和小于跨數(shù)據(jù)中心鏈路容量的寫入速率，這種延遲非常小。然而，應該注意，在突然停止復制并手動切換到集群B的情況下，一些最近編寫的更新可能會丟失。

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

最后，到目前為止，關閉復制并開始使用復制副本是一種手動操作，需要管理員做出決定和采取行動。