[[330283]]

大家聽過 MySQL MGR 技術嗎？

MySQL 是目前最流行的開源關系型數據庫，國內金融行業也開始全面使用，其中MySQL 5.7.17 提出的 MGR（MySQL Group Replication）既可以很好的保證數據一致性又可以自動切換，具備故障檢測功能、支持多節點寫入，MGR 是一項被普遍看好的技術。本文給大家介紹一下 MySQL MGR 技術演變過程、事務生命周期及事務沖突檢測機制。

先介紹 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所示，三個人對話，一個人在不停歇的演講，不需要知道兩個聽眾是否聽懂，聽眾也不需要做出回應，等演講完畢，有可能聽眾沒聽懂，最終大家認知到信息可能不一致，為了解決上述問題MySQL5.5.8 就有了半同步復制。

 

圖3 異步復制場景模擬圖

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

圖4 半同步示意圖

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

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

MySQL 5.7 版本的MGR技術可以解決上述問題。

圖5 半同步復制場景模擬

至此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 層內部處理過程。

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集群中從開始到結束整個處理過程，接下從局部角度詳細介紹沖突檢測機制實現機制。

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 結構圖

沖突檢測核心機制！敲黑板！

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

反之，事務T3，更新id=1的行，事務T3的UUID_MGR為1-100, 節點中沖突檢測模塊中的certification info中的UUID_MGR為1-101，很明顯T3:UUID_MGR:1-100<UUID_MGR:1-101，則T3沖突檢測失敗，事務回滾或者丟棄。

上面是針對于單獨一個寫來進行判斷，現在我們來展示一下多節點模式中，多個事務同時寫入時沖突檢測機制。如下圖所示，三個事務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信息。

MGR技術特點有哪些？

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

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

支持多節點寫入，具備沖突檢測機制，可以適應多種應用場景需求。

圖13 MGR技術閃亮點

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

總結展望

MySQL是應用最廣泛的一個開源數據庫 ，其中MGR技術在保證數據一致性基礎上，可自動進行故障檢測、自動切換，具備防腦裂機制，兼具多節點寫入等優點，是一個很好的技術發展方向。目前部分銀行應用MySQL比例較高，并且也已開始推廣上線MGR架構；G行數據庫數據庫規劃秉持傳統數據庫和開源數據庫并行使用模式，MySQL線上應用也有上百套，其中的A類系統中的分布式企業總線開始應用實踐MGR技術。后續還將持續推廣該項技術，不斷提升開源數據庫技術管理水平。

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