[[330283]]

大家聽過 MySQL MGR 技術(shù)嗎？

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

先介紹 MGR 技術(shù)演進(jìn)

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

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

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

 

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

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

 

圖3 異步復(fù)制場(chǎng)景模擬圖

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

圖4 半同步示意圖

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

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

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

圖5 半同步復(fù)制場(chǎng)景模擬

至此MGR技術(shù)誕生！

MGR （MySQL Group Replication）是 MySQL 自帶的一個(gè)插件，可以靈活部署。MySQL MGR 集群是多個(gè) MySQL Server 節(jié)點(diǎn)共同組成的分布式集群，每個(gè) Server 都有完整的副本，它是基于 ROW 格式的二進(jìn)制日志文件和 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é)議層進(jìn)行事務(wù)傳輸，最后經(jīng)過GCS API+Paxos引擎層保證事務(wù)在各個(gè)節(jié)點(diǎn)數(shù)據(jù)最終一致性。這是事務(wù)進(jìn)入 MGR 層內(nèi)部處理過程。

MGR 集群中事務(wù)整個(gè)生命周期啥樣？

接下來從全局角度看事務(wù)整個(gè)生命周期，如下圖7所示，DB1 、DB2 、DB3構(gòu)成的MGR集群， 集群中每個(gè)DB都有MGR層，MGR層功能也可簡(jiǎn)單理解為由Paxos模塊和沖突檢測(cè)Certify模塊實(shí)現(xiàn)。Paxos模塊是基于Paxos算法確保所有節(jié)點(diǎn)收到相同廣播消息，transaction message就是廣播消息的內(nèi)容結(jié)構(gòu)；沖突檢測(cè)Certify模塊進(jìn)行沖突檢測(cè)確保數(shù)據(jù)最終一致性，其中certification info是沖突檢測(cè)中內(nèi)存結(jié)構(gòu)；本文詳細(xì)介紹沖突檢測(cè)模塊實(shí)現(xiàn)原理，Paxos算法實(shí)現(xiàn)部分后續(xù)對(duì)比Raft算法詳細(xì)介紹。

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

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

 

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

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

transaction message和certification info分別是什么？

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

1 transaction message

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

具體組成：

• write set 叫寫入集合，是事務(wù)更新行相關(guān)信息的Hash值。

write set=Hash（庫(kù)名+表名+主鍵（唯一鍵）字段信息）

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é)點(diǎn)。

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

2 certification info

廣播的信息到達(dá)沖突檢測(cè)模塊certification之后是如何工作？

每個(gè)節(jié)點(diǎn)都有一個(gè)certification info的內(nèi)存結(jié)構(gòu)，certification info保存了通過沖突檢測(cè)的事務(wù)的write set和gtid_executed。certification info相當(dāng)于一個(gè)map，key是string結(jié)構(gòu)，保存write set中提取的主鍵值；value是set集合，保存gtid_executed事務(wù)快照版本；例如T1事務(wù)，T1更新數(shù)據(jù)庫(kù)d1中的表t1中兩行數(shù)據(jù)id=1和id=2，它對(duì)應(yīng)快照版本UUID_MGR是:1-100，剛開始certification info為空，所以直接提交，之后certification info中快照版本直接更新為1-101.

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

沖突檢測(cè)核心機(jī)制！敲黑板！

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

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

上面是針對(duì)于單獨(dú)一個(gè)寫來進(jìn)行判斷，現(xiàn)在我們來展示一下多節(jié)點(diǎn)模式中，多個(gè)事務(wù)同時(shí)寫入時(shí)沖突檢測(cè)機(jī)制。如下圖所示，三個(gè)事務(wù)T4、T5、T6并行寫入某個(gè)MySQL節(jié)點(diǎn)，通過了Paxos協(xié)議模塊達(dá)成一致性共識(shí)，進(jìn)行沖突檢測(cè)時(shí)遵循下面三個(gè)原則：

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

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

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

事務(wù)T4，更新id=1的行，事務(wù)T4的UUID_MGR為1-102, 節(jié)點(diǎn)中沖突檢測(cè)模塊中的certification info中id=1的UUID_MGR為1-101,很明顯T2:UUID_MGR:1-102>UUID_MGR:1-101,則T4沖突檢測(cè)通過,更新為certification info中UUID_MGR為1-103。

事務(wù)T5，更新id=1的行，事務(wù)T5的UUID_MGR為1-100, 節(jié)點(diǎn)中沖突檢測(cè)模塊中的certification info中id=1的UUID_MGR為1-102,其中T5:UUID_MGR:1-100>UUID_MGR:1-102,則T5沖突檢測(cè)不通過。

事務(wù)T6，更新id=3的行，事務(wù)T6的UUID_MGR為1-100, 節(jié)點(diǎn)中沖突檢測(cè)模塊中的certification info中id=3的UUID_MGR為空,其中T6:UUID_MGR:1-100>UUID_MGR,則T6沖突檢測(cè)通過,更新為certification info中UUID_MGR為1-101。

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

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

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

MGR技術(shù)特點(diǎn)有哪些？

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

• MGR是基于Paxos協(xié)議和原生復(fù)制的分布式集群，大多數(shù)節(jié)點(diǎn)同意即可以通過議題的模式，數(shù)據(jù)一致性高。
• 具備高可用、自動(dòng)故障檢測(cè)功能，可自動(dòng)切換。
• 可彈性擴(kuò)展，集群自動(dòng)的新增和移除節(jié)點(diǎn)，集群最多接入9個(gè)節(jié)點(diǎn)。
• 有單主和多主模式。

支持多節(jié)點(diǎn)寫入，具備沖突檢測(cè)機(jī)制，可以適應(yīng)多種應(yīng)用場(chǎng)景需求。

圖13 MGR技術(shù)閃亮點(diǎn)

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

總結(jié)展望

MySQL是應(yīng)用最廣泛的一個(gè)開源數(shù)據(jù)庫(kù) ，其中MGR技術(shù)在保證數(shù)據(jù)一致性基礎(chǔ)上，可自動(dòng)進(jìn)行故障檢測(cè)、自動(dòng)切換，具備防腦裂機(jī)制，兼具多節(jié)點(diǎn)寫入等優(yōu)點(diǎn)，是一個(gè)很好的技術(shù)發(fā)展方向。目前部分銀行應(yīng)用MySQL比例較高，并且也已開始推廣上線MGR架構(gòu)；G行數(shù)據(jù)庫(kù)數(shù)據(jù)庫(kù)規(guī)劃秉持傳統(tǒng)數(shù)據(jù)庫(kù)和開源數(shù)據(jù)庫(kù)并行使用模式，MySQL線上應(yīng)用也有上百套，其中的A類系統(tǒng)中的分布式企業(yè)總線開始應(yīng)用實(shí)踐MGR技術(shù)。后續(xù)還將持續(xù)推廣該項(xiàng)技術(shù)，不斷提升開源數(shù)據(jù)庫(kù)技術(shù)管理水平。

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