1. 大家聽過 MySQL MGR 技術(shù)嗎?

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

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

2. MGR 技術(shù)演進

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

圖 1：主從復(fù)制示意圖

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

圖 2：異步復(fù)制示意圖

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

圖 3：異步復(fù)制場景模擬圖

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

圖 4：半同步示意圖

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

這種復(fù)制模式也存在兩個問題：

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

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

圖 5：半同步復(fù)制場景模擬

3. 至此 MGR 技術(shù)誕生!

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

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

如下圖 6 所示為 MGR 架構(gòu)圖，主要是 APIs 層、組件層、復(fù)制協(xié)議模塊層和 GCS API+Paxos 引擎層構(gòu)成。

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

圖 6：MGR 架構(gòu)示意圖

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

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

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

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

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

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

圖 7：MGR 組復(fù)制技術(shù)示意圖

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

5. transaction message 和 certification info

分別是什么?

介紹沖突檢測實現(xiàn)原理之前，先介紹一下廣播信息 transaction message、沖突檢測內(nèi)存 certification info 的結(jié)構(gòu)組成。

(1) transaction message

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

具體組成：

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

圖 8：廣播信息的內(nèi)容結(jié)構(gòu)

(2) certification info

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

每個節(jié)點都有一個 certification info 的內(nèi)存結(jié)構(gòu)，certification info 保存了通過沖突檢測的事務(wù)的 write set 和 gtid_executed。

certification info 相當(dāng)于一個 map，key 是 string 結(jié)構(gòu)，保存 write set 中提取的主鍵值;value 是 set 集合，保存 gtid_executed 事務(wù)快照版本。

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

圖 9：certification info 結(jié)構(gòu)圖

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

通過上面的例子可知通過沖突檢測標(biāo)準(zhǔn)：若 transaction UUID_MGR ">="certification info UUID_MGR，則沖突檢測通過。

圖 10：沖突檢測事務(wù)執(zhí)行舉例

根據(jù)上述標(biāo)準(zhǔn)舉例，事務(wù) T2，更新 id=2 的行，事務(wù) T2 的 UUID_MGR 為 1-102，節(jié)點中沖突檢測模塊中的 certification info 中的 UUID_MGR 為 1-101，這里 T2:UUID_MGR:1-102>UUID_MGR:1-100，則 T2 沖突檢測通過。

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

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

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

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

圖 11：多事務(wù)同時寫入示意圖

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

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

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

圖 12：多事務(wù)同時寫入結(jié)果圖

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

7. MGR 技術(shù)特點有哪些?

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

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

圖 13：MGR 技術(shù)閃亮點

MGR 目前還存在一些功能限制和不足，但是是未來數(shù)據(jù)庫發(fā)展的一個趨勢，隨著產(chǎn)品不斷完善，MGR 必將引領(lǐng)數(shù)據(jù)庫系統(tǒng)發(fā)展的潮流。

8. 總結(jié)展望

MySQL 是應(yīng)用最廣泛的一個開源數(shù)據(jù)庫 ，其中 MGR 技術(shù)在保證數(shù)據(jù)一致性基礎(chǔ)上，可自動進行故障檢測、自動切換，具備防腦裂機制，兼具多節(jié)點寫入等優(yōu)點，是一個很好的技術(shù)發(fā)展方向。

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

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

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

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

掃描下方二維碼觀看回放