摘要：?MongoDB云上災備BLS產(chǎn)品正式發(fā)布

1. 背景

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

2. 產(chǎn)品介紹

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

全量加增量

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

雙活以及多活模型

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

高效性保證

??同步延遲因地域和網(wǎng)絡不同而不同，理論TPS能夠接近20萬（每秒傳輸20萬條oplog）。為了保證批量傳輸?shù)母咝?，?shù)據(jù)發(fā)送存在緩存機制，所以少量數(shù)據(jù)的同步時延可能超過5秒。

• 源數(shù)據(jù)庫并行拉取，解決沖突依賴

• 并行發(fā)往Kafka通道

• 目的端在解決依賴的同時并行寫入數(shù)據(jù)庫

環(huán)形復制

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

可靠性傳輸

??支持斷點續(xù)傳，實例重啟時數(shù)據(jù)同步不受影響。

高可用

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

限制說明

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

• 目的數(shù)據(jù)庫需要創(chuàng)建，暫不支持在2個已有MongoDB實例之間直接搭通道。

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

3. 架構

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

• BLS Manager。中心控制模塊，負責Collector、Receiver的調(diào)度、監(jiān)控等任務。

• BLS Collector。數(shù)據(jù)采集模塊，負責從源MongoDB數(shù)據(jù)庫拉取Oplog數(shù)據(jù)后發(fā)送到Kafka通道。

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

下圖展示了系統(tǒng)的整體架構圖。

4. 用戶使用案例

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

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

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

原文鏈接

本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。