概述：

利用主從復制+

GTID

的特性實現異地數據同步與讀寫分離。下面是實現細節與不同于常規方案的特性。

實現背景

是為了將分屬兩個不同集群的實例，建立同步關系。備實例會自動選擇主實例中延遲較小的備機建立同步，當該主實例備機發生故障時，會自動與另一個備機建立同步關系。

DCN同步建立后，主實例可寫，備實例只讀。這可作為一種異地容災方案，也可作為一種異地讀寫方案

，參照

D

CN

技術分為兩步：

第一部分：

在主備機房中，如圖2

在主機房一主兩備中，master提交事務后，寫入binlog，通過mysql主從復制協議，master機將binlog傳輸到任意slave機，然后slave機回放relaylog，最終完成主從復制。第二部分：如圖1，主備機房完成建立DCN同步后，備機房的master機會從主機房中主備延遲最小的slave機上的拉取binlog，隨后回放binlog。

第

二

部分：

如果主機房當前已經建立DCN同步的slave機器故障了，會自動與另一個備機建立同步關系如圖2

主從同步的方式實現異地容災方案比較成熟，但仍需要解決一些核心問題。

1.

由于存在“級聯復制”的情況，那么如何準備的計算延遲？

2.

如果實例需要進行擴容時，同步關系是否收到影響，作為異地讀寫分離的場景，級聯節點數據延遲擴大如何解決？

針對上述問題：

1.

計算延遲

a)

不采用

Seconds_Behind_Master

的值作為延遲依據，主機

agent不停地向主機數據庫寫入帶有當前時間戳的記錄，這些記錄會同步到備機數據庫中

備機的

agent根據數據庫中最新的記錄與機器當前時間戳，就可以計算出實時延遲時間了

，然后備機

agent再將這些信息(包括實時延遲與延遲的主機信息)寫入到zk中，告知其它模塊

，而這些信也息作為scheduler仲裁擴容的依據。

b)

如下圖延遲的計算過程，在擴容的同步數據步驟中

M每寫入一條時間戳記錄，目標實例中的所有節點都會同步到該條記錄，然后上報到zk中，當scheduler發現所有節點的延遲小于5秒，且delayip都是M(這點主要是防止異常)時，進入到下一個流程

2.實例進行擴容的時候，集群具備自動更新

dcn同步關系的功能，并且在擴容過程中

不需要人為介入，減少了

延遲

得

影響

。由程序介入，并分拆為三步：

a)

建立原實例與目標實例的同步關系

b)

檢測目標實例與原實例之間的延遲，當延遲小于

5S時，設置原實例只讀，拒絕掉新的寫入

c)

檢測目標實例與原實例之間的

gtid，當gtid無差別時，斷開原實例與目標實例之間的同步關系，并將Proxy路由切換到目標實例

d)

下圖表示利用D

CN

進行集群擴容的流程：

i.

MM表示主實例的主機，MS表示主實例備機，MSET表示主實例。SM表示備實例主機，SS表示備實例備機，SSET表示備實例。EMM表示主實例擴容的目標實例的主機，EMS表示主實例擴容的目標實例的備機，EMSET表示主實例擴容的目標實例。ESM表示備實例擴容的目標機器的主機，ESS表示備實例擴容的目標機器的備機，ESSET表示備實例擴容的目標實例

擴容流程：

(

1)建立EMSET與MSET之間的擴容同步關系。

(

2)檢測到EMSET與MSET之間的延遲小于5秒時，斷開SSET與MSET之間的DCN同步關系。(

提前斷開是為了防止后續S

SET

的

GTID

的信息不被

EMSET

的

GTID

列表包含，這里的差異信息可能是

MM

節點與E

MSET

斷開后新寫入Z

K

的時間戳記錄

)

(

3)確認SSET與MSET之間的DCN同步關系斷開后，設置MSET為隔離狀態(此時網關會拒絕掉所有新的連接)，并向EMM節點的agent發送擴容處理任務。

(

4)當EMM節點的agent接收到scheduler發送的擴容處理后，設置MM節點只讀，并計算EMM與MM節點gtid的差值，當gtid無差值時，反饋scheduler任務處理成功。如果期間設置只讀失敗，反饋sheduler處理失敗。

(

5)Scheduler根據agent反饋進行區分處理，反饋成功進入步驟6，反饋失敗進入步驟7。

(

6)斷開EMSET與MSET之間的擴容同步關系，返回擴容成功，并建立EMSET與SSET之間的DCN同步關系。

(

7)把MSET設置為正常狀態(網關正常接收新連接)，返回擴容失敗，并重建MSET與SSET之間的DCN關系。

總結

以上是生活随笔為你收集整理的mysql dcn_Tdsql DCN同步技术原理介绍的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。