1. 大家聽過 MySQL MGR 技術嗎?

MySQL 是目前最流行的開源關系型數據庫，國內金融行業也開始全面使用，其中 MySQL 5.7.17 提出的 MGR(MySQL Group Replication)既可以很好的保證數據一致性又可以自動切換，具備故障檢測功能、支持多節點寫入，MGR 是一項被普遍看好的技術。

本文給大家介紹一下 MySQL MGR 技術演變過程、事務生命周期及事務沖突檢測機制。

2. MGR 技術演進

傳統的 MySQL 主從復制架構是 MySQL 保持數據一致性的最基本架構，如下圖 1 所示，一主一從架構，從庫給主庫發起讀數據請求后，主庫會通過 dump線程把 binlog 日志文件推送給從庫，從庫的 I/O 線程把接收到數據更新到 relay log，之后從庫的 SQL 線程把 relay log 應用為 binlog 日志，直到主庫與從庫的 binlog 日志文件完全數據一致，達到主從同步。

圖 1：主從復制示意圖

接下來我們看一下 MySQL 異步復制，如下圖 2 所示，一主兩從架構，應用發來的事務請求，經過執行之后寫入 binlog，主庫 master 把 binlog 日志推送給從庫 salve1 和 slave2 ，主庫不需要等到從庫是否成功更新數據到 relay log，主庫直接提交事務即可。這種模式犧牲了數據一致性，不能很好保證主從數據一致性。

圖 2：異步復制示意圖

模擬異步復制場景舉例，如下圖 3 所示，三個人對話，一個人在不停歇的演講，不需要知道兩個聽眾是否聽懂，聽眾也不需要做出回應，等演講完畢，有可能聽眾沒聽懂，最終大家認知到信息可能不一致，為了解決上述問題 MySQL 5.5.8 就有了半同步復制。

圖 3：異步復制場景模擬圖

接下來看一下 MySQL 的半同步復制，如下圖 4 所示，一主兩從架構，應用發來的事務請求，在主庫執行后寫入 binlog，主庫 master 把 binlog 日志推送給從庫 salve1 和 slave2 ，半同步主庫需要等待其中任意一個從庫更新數據到 relay log 成功并且告知主庫，主庫才提交事務，這樣保證至少有一個從庫同步上數據了，也縮短了延遲時間，保證了數據安全。

圖 4：半同步示意圖

模擬半同步復制場景舉例，如下圖 5 所示，三個人對話，一個人在不停歇的演講，任意一個聽眾回應聽懂了，演講者就繼續往下說，否則停止演講，最后等演講結束，至少一聽眾聽懂演講者的意思，保證信息傳遞一致性。

這種復制模式也存在兩個問題：

• MySQL 無法自動切換，需要借助外力切庫，運維復雜。
• 從庫 Slave 的讀壓力太大會導致復制延遲不斷增加。

MySQL5.7 版本的 MGR 技術可以解決上述問題。

圖 5：半同步復制場景模擬

3. 至此 MGR 技術誕生!

MGR(MySQL Group Replication)是 MySQL 自帶的一個插件，可以靈活部署。

MySQL MGR 集群是多個 MySQL Server 節點共同組成的分布式集群，每個 Server 都有完整的副本，它是基于 ROW 格式的二進制日志文件和 GTID 特性。

如下圖 6 所示為 MGR 架構圖，主要是 APIs 層、組件層、復制協議模塊層和 GCS API+Paxos 引擎層構成。

如圖 6 所示，應用發來的事務從 MySQL Server 經過 MGR 的 APIs 接口層分發到組件層，組件層去 capture 事務相關信息，然后經過復制協議層進行事務傳輸，最后經過 GCS API+Paxos 引擎層保證事務在各個節點數據最終一致性。這是事務進入 MGR 層內部處理過程。

圖 6：MGR 架構示意圖

4. MGR 集群中事務整個生命周期啥樣?

接下來從全局角度看事務整個生命周期，如下圖 7 所示，DB1 、DB2 、DB3 構成的 MGR 集群， 集群中每個 DB 都有 MGR 層，MGR 層功能也可簡單理解為由 Paxos 模塊和沖突檢測 Certify 模塊實現。

Paxos 模塊是基于 Paxos 算法確保所有節點收到相同廣播消息，transaction message 就是廣播消息的內容結構;沖突檢測 Certify 模塊進行沖突檢測確保數據最終一致性，其中 certification info 是沖突檢測中內存結構。

本文詳細介紹沖突檢測模塊實現原理，Paxos 算法實現部分后續對比 Raft 算法詳細介紹。

當 DB1 上有事務 T1 要執行時，T1 對 DB1 是來說本地事務，對于 DB2、DB3 來說是遠端事務;DB1 上在事務 T1 在被執行后，會把執行事務 T1 信息廣播給集群各個節點，包括 DB1 本身，通過 Paxos 模塊廣播給 MGR 集群各個節點，半數以上的節點同意并且達成共識，之后共識信息進入各個節點的沖突檢測 certify 模塊，各個節點各自進行沖突檢測驗證，最終保證事務在集群中最終一致性。

在沖突檢測通過之后，本地事務 T1 在 DB1 直接提交即可，否則直接回滾。遠端事務 T1 在 DB2 和 DB3 分別先更新到 relay log，然后應用到 binlog，完成數據的同步，否則直接放棄該事務。

圖 7：MGR 組復制技術示意圖

前面我們從全局視角介紹了一個事務在 MGR 集群中從開始到結束整個處理過程，接下從局部角度詳細介紹沖突檢測機制實現機制。

5. transaction message 和 certification info

分別是什么?

介紹沖突檢測實現原理之前，先介紹一下廣播信息 transaction message、沖突檢測內存 certification info 的結構組成。

(1) transaction message

如圖 8 所示，transaction message 保存是事務 T1 要更新行的的相關信息,有 transaction_context_log_event 和 gtid_log_event 及 log_event_group 三部分組成。

具體組成：

• write set 叫寫入集合，是事務更新行相關信息的 Hash 值。write set=Hash(庫名+表名+主鍵(唯一鍵)字段信息)
• gtid_executed 為已經執行過的事務 gtid 集合，也即事務快照版本。
• 把 write set 和 gtid_executed 打包成為事務上下文信息，transaction_context_log_event。
• gtid_log_event為已經執行過的事務 gtid 集合。
• log_event_group 為事務日志信息，后續要更新到 relay log 中。
• 把 3 和 4 和 5 一起打包成為 transaction message 廣播給其它節點。

圖 8：廣播信息的內容結構

(2) certification info

廣播的信息到達沖突檢測模塊 certification 之后是如何工作?

每個節點都有一個 certification info 的內存結構，certification info 保存了通過沖突檢測的事務的 write set 和 gtid_executed。

certification info 相當于一個 map，key 是 string 結構，保存 write set 中提取的主鍵值;value 是 set 集合，保存 gtid_executed 事務快照版本。

例如 T1 事務，T1 更新數據庫 d1 中的表 t1 中兩行數據 id=1 和 id=2，它對應快照版本 UUID_MGR 是 :1-100，剛開始 certification info 為空，所以直接提交，之后 certification info 中快照版本直接更新為 1-101。

圖 9：certification info 結構圖

6. 沖突檢測核心機制!敲黑板!

通過上面的例子可知通過沖突檢測標準：若 transaction UUID_MGR ">="certification info UUID_MGR，則沖突檢測通過。

圖 10：沖突檢測事務執行舉例

根據上述標準舉例，事務 T2，更新 id=2 的行，事務 T2 的 UUID_MGR 為 1-102，節點中沖突檢測模塊中的 certification info 中的 UUID_MGR 為 1-101，這里 T2:UUID_MGR:1-102>UUID_MGR:1-100，則 T2 沖突檢測通過。

反之，事務 T3，更新 id=1 的行，事務 T3 的 UUID_MGR 為 1-100, 節點中沖突檢測模塊中的 certification info 中的 UUID_MGR 為 1-101，很明顯 T3:UUID_MGR:1-100

上面是針對于單獨一個寫來進行判斷，現在我們來展示一下多節點模式中，多個事務同時寫入時沖突檢測機制。

如下圖所示，三個事務 T4、T5、T6 并行寫入某個 MySQL 節點，通過了 Paxos 協議模塊達成一致性共識，進行沖突檢測時遵循下面三個原則：

• 多個事務修改同一個 id 對應的數值，需要按照先后順序進行沖突檢測。
• 多個事務同時對不同的 id 進行修改，各自進行修改即可。
• 不同的事務對同一個 id 修改，需要按照先后順序進行沖突檢測即。

圖 11：多事務同時寫入示意圖

如圖 11 所示，事務 T4 和事務 T5 同時更新 id=1 的行，按照先來后到順序進行沖突檢測，T4 先到先進行沖突檢測。

• 事務 T4，更新 id=1 的行，事務 T4 的 UUID_MGR 為 1-102，節點中沖突檢測模塊中的 certification info 中 id=1 的 UUID_MGR 為 1-101，很明顯 T2:UUID_MGR:1-102>UUID_MGR:1-101，則 T4 沖突檢測通過，更新為 certification info 中 UUID_MGR 為 1-103。
• 事務 T5，更新 id=1 的行，事務 T5 的 UUID_MGR 為 1-100, 節點中沖突檢測模塊中的 certification info 中 id=1 的 UUID_MGR 為 1-102，其中 T5:UUID_MGR:1-100>UUID_MGR:1-102，則 T5 沖突檢測不通過。
• 事務 T6，更新 id=3 的行，事務 T6 的 UUID_MGR 為 1-100, 節點中沖突檢測模塊中的 certification info 中 id=3 的 UUID_MGR 為空，其中 T6:UUID_MGR:1-100>UUID_MGR，則 T6 沖突檢測通過,更新為 certification info 中 UUID_MGR 為 1-101。

如下圖 12 所示，事務 T4 和事務 T5 并行修改 id=1，T4 寫入成功，T5 丟棄，T6 寫入 id=3 事務，寫入成功。

圖 12：多事務同時寫入結果圖

隨著 write set 不斷寫入 certification info 中，內存消耗會相應增大，MGR 有配套的 write set 清理線程，每隔一段時間去清理已經在節點應用或者回放的事務的 write set 信息。

7. MGR 技術特點有哪些?

如下圖 13 所示，MGR 具備以下技術特點：

• MGR 是基于 Paxos 協議和原生復制的分布式集群，大多數節點同意即可以通過議題的模式，數據一致性高。
• 具備高可用、自動故障檢測功能，可自動切換。
• 可彈性擴展，集群自動的新增和移除節點，集群最多接入 9 個節點。
• 有單主和多主模式。支持多節點寫入，具備沖突檢測機制，可以適應多種應用場景需求。

圖 13：MGR 技術閃亮點

MGR 目前還存在一些功能限制和不足，但是是未來數據庫發展的一個趨勢，隨著產品不斷完善，MGR 必將引領數據庫系統發展的潮流。

8. 總結展望

MySQL 是應用最廣泛的一個開源數據庫 ，其中 MGR 技術在保證數據一致性基礎上，可自動進行故障檢測、自動切換，具備防腦裂機制，兼具多節點寫入等優點，是一個很好的技術發展方向。

目前部分銀行應用 MySQL 比例較高，并且也已開始推廣上線 MGR 架構;G 行數據庫數據庫規劃秉持傳統數據庫和開源數據庫并行使用模式，MySQL 線上應用也有上百套，其中的 A 類系統中的分布式企業總線開始應用實踐 MGR 技術。后續還將持續推廣該項技術，不斷提升開源數據庫技術管理水平。

最后跟大家梳理一下文章內容，先介紹 MySQL MGR 技術演變過程，然后全局闡述了事務生命周期，最后詳細解釋了事務沖突檢測機制，文章略長但干貨夠足，大家看懂了沒?

本文整理自光大銀行信息科技部杜蓉在《大咖來了》的直播分享：

《DBA 女神帶你從 0 到 1 揭秘 MGR》

掃描下方二維碼觀看回放