摘要：?MongoDB云上災備BLS產品正式發布

1. 背景

??當前的數據庫系統生態中，大部分系統都支持多個節點實例間的數據同步機制 ，如Mysql Master/Slave主從同步，Redis AOF主從同步等，MongoDB更是支持3節點(及以上)ReplicaSet同步，上述機制很好的支撐了一個邏輯單元的數據冗余及HA。
??跨邏輯單元(3節點實例、主從實例)，甚至跨單元、跨數據中心的數據同步，在業務層有時候就顯得很重要，可以支持同城多機房的負載均衡，多機房的互備，甚至是異地多數據中心容災(比如 光纖被挖斷、地震等小概率事件)和多活。
??基于以上背景，云數據庫MongoDB版本正式推出MongoDB實例間的雙向同步產品“MongoDB云上災備”（也稱BLS），助力企業快速復制阿里巴巴異地災備、多活架構。
??產品地址

2. 產品介紹

??“MongoDB云上災備”通過從源數據庫拉取Oplog（Operations Log）數據（其是MongoDB的日志，所有對數據庫的修改操作都會保存到oplog中），然后將其傳輸到目的數據庫進行回放實現復制的目的。我們通過構造兩條復制鏈路實現雙向同步的功能，基于此，可以實現災備和多活的功能。
??上圖給出了整體復制同步的流程。目前，“MongoDB云上災備”支持的源、目的數據庫類型為ReplicaSet副本集，Sharding模式即將上線，不支持單節點模式。為了減緩主節點的壓力，系統從備（Secondary）上拉取Oplog。

全量加增量

??同步模型采用全量+增量的方式：在創建時會對源數據庫進行全量同步，后續的修改通過增量來同步。

雙活以及多活模型

??由于復制是異步模式，所以對于雙活/多活模式，由用戶保證不會對同一個唯一鍵同時修改，因為同時修改將可能導致數據錯亂。目前沖突策略可以為覆蓋或者忽略。后續將會上線校驗程序，在用戶操作相同唯一鍵時提供接口報錯。

高效性保證

??同步延遲因地域和網絡不同而不同，理論TPS能夠接近20萬（每秒傳輸20萬條oplog）。為了保證批量傳輸的高效性，數據發送存在緩存機制，所以少量數據的同步時延可能超過5秒。

• 源數據庫并行拉取，解決沖突依賴

• 并行發往Kafka通道

• 目的端在解決依賴的同時并行寫入數據庫

環形復制

??為了防止環形復制（數據從源復制到目的，又從目的復制到源），在Oplog日志中打入gid解決該問題。

可靠性傳輸

??支持斷點續傳，實例重啟時數據同步不受影響。

高可用

??鏈路同步具有高可用性，如果同步進程掛掉，會有備進程啟動接管服務。

限制說明

• DDL語句同步暫未開放，所以如果修改了源、目的數據的索引操作，無法同步。

• 目的數據庫需要創建，暫不支持在2個已有MongoDB實例之間直接搭通道。

• 當前只支持雙活功能(2個MongoDB實例之間同步數據)，后續會上線多活功能(多個MongoDB實例之間同步數據)。

3. 架構

??在“MongoDB云上災備”產品中，主要有3大組件：

• BLS Manager。中心控制模塊，負責Collector、Receiver的調度、監控等任務。

• BLS Collector。數據采集模塊，負責從源MongoDB數據庫拉取Oplog數據后發送到Kafka通道。

• BLS Receiver。數據回放模塊，負責從Kafka通道中獲取數據，然后寫入目的MongoDB數據庫。

下圖展示了系統的整體架構圖。

4. 用戶使用案例

??高德地圖 App是國內首屈一指的地圖及導航應用，阿里云MongoDB數據庫服務為該應用提供了部分功能的存儲支撐，存儲億級別數據。現在高德使用國內三中心的策略，通過地理位置等信息路由最近中心提升服務質量，業務方(高德地圖)通過用戶路由到三個城市數據中心，如下圖所示，機房數據之間無依賴計算。數據在不同中心的同步通過“MongoDB云上災備”產品實現。

??這三個城市地理上從北到南橫跨了整個中國 ，這對多數據中心如何做好復制、容災提出了挑戰，如果某個地域的機房、網絡出現問題，可以平滑的將流量切換到另一個地方，做到用戶幾乎無感知？
??目前策略是，拓撲采用機房兩兩互聯方式，每個機房的數據都通過“MongoDB云上災備”異步地將數據同步到另外兩個機房。然后通過高德的路由層，將用戶請求路由到不同的數據中心，讀寫均發送在同一個數據中心，保證一定的事務性。這樣保證每個數據中心都有全量的數據(保證最終一致性) 。任意機房出現問題，另兩個機房中的一個可以通過切換后提供讀寫服務。下圖展示了城市1和城市2機房的同步情況。

遇到某個單元不能訪問的問題，Manager通過“MongoDB云上災備”產品管理接口，可以獲得各個機房的同步偏移量和時間戳，通過判斷采集和寫入值即可判斷異步復制是否在某個時間點已經完成。再配合業務方的DNS切流，切走單元流量并保證原有單元的請求在新單元是可以讀寫的，如下圖所示。

原文鏈接

本文為云棲社區原創內容，未經允許不得轉載。