【恩墨學院】深入剖析 Group Replication核心的引擎特性

小編寄語

主庫master與從庫slave的切換不管是主動的還是被動的都需要外部干預才能進行，這與資料庫核心本身是按照單機來設計的理念悉悉相關，並且資料庫系統本身也沒有提供管理多個例項的能力，當slave數目不斷增多時，這對資料庫管理員來說就是一個巨大的負擔。那麼，深入瞭解Group Replication核心的引擎特性就顯得異常重要了。接下來我們就深入剖析一下其引擎特性。

背景

為了建立高可用資料庫系統，傳統的實現方式是建立一個或多個備用的資料庫例項，原有的資料庫例項通常稱為主庫master，其它備用的資料庫例項稱為備庫或從庫slave。當master故障無法正常工作後，slave就會接替其工作，保證整個資料庫系統不會對外中斷服務。

MySQL的傳統主從複製機制

 

MySQL傳統的高可用解決方案是透過binlog複製來搭建主從或一主多從的資料庫叢集。主從之間的複製模式支援非同步模式(async replication)和半同步模式(semi-sync replication)。無論哪種模式下，都是主庫master提供讀寫事務的能力，而slave只能提供只讀事務的能力。在master上執行的更新事務透過binlog複製的方式傳送給slave，slave收到後將事務先寫入relay log，然後重放事務，即在slave上重新執行一次事務，從而達到主從機事務一致的效果。

上圖是非同步複製(Async replication)的示意圖,在master將事務寫入binlog後，將新寫入的binlog事務日誌傳送給slave節點，但並不等待傳送的結果，就會在儲存引擎中提交事務。

 

上圖是半同步複製(Semi-sync replication)的示意圖，在master將事務寫入binlog後，將新寫入的binlog事務日誌傳送給slave節點，但需要等待slave返回傳送的結果；slave收到binlog事務後，將其寫入relay log中，然後向master返回傳送成功ACK；master收到ACK後，再在儲存引擎中提交事務。

MySQL基於兩種複製模式都可以搭建高可用資料庫叢集，也能滿足大部分高可用系統的要求，但在對事務一致性要求很高的系統中，還是存在一些不足，主要的不足就是主從之間的事務不能保證時刻完全一致。

1、基於非同步複製的高可用方案存在主從不一致乃至丟失事務的風險，原因在於當master將事務寫入binlog，然後複製給slave後並不等待slave回覆即進行提交，若slave因網路延遲或其它問題尚未收到binlog日誌，而此時master故障，應用切換到slave時，本來在master上已經提交的事務就會丟失，因其尚未傳送到slave，從而導致主從之間事務不一致。

2、基於semi-sync複製的高可用方案也存在主備不一致的風險，原因在於當master將事務寫入binlog，尚未傳送給slave時master故障，此時應用切換到slave，雖然此時slave的事務與master故障前是一致的，但當主機恢復後，因最後的事務已經寫入到binlog，所以在master上會恢復成已提交狀態，從而導致主從之間的事務不一致。

Group Replication應運而生

 

為了應對事務一致性要求很高的系統對高可用資料庫系統的要求，並且增強高可用叢集的自管理能力，避免節點故障後的failover需要人工干預或其它輔助工具干預，MySQL5.7新引入了Group Replication，用於搭建更高事務一致性的高可用資料庫叢集系統。

基於Group Replication搭建的系統，不僅可以自動進行failover，而且同時保證系統中多個節點之間的事務一致性，避免因節點故障或網路問題而導致的節點間事務不一致。此外還提供了節點管理的能力，真正將整個叢集做為一個整體對外提供服務。

Group Replication的實現原理

 

Group Replication由至少3個或更多個節點共同組成一個資料庫叢集，事務的提交必須經過半數以上節點同意方可提交，在叢集中每個節點上都維護一個資料庫狀態機，保證節點間事務的一致性。Group Replication基於分散式一致性演算法Paxos實現，允許部分節點故障，只要保證半數以上節點存活，就不影響對外提供資料庫服務，是一個真正可用的高可用資料庫叢集技術。

在多主模式下，每個節點都可以對外提供讀寫事務的服務。但在多主模式下，多個節點間的事務可能有比較大的衝突，從而影響效能，並且對查詢語句也有更多的限制，具體限制可參見使用手冊。多主模式的叢集如下圖所示：

MySQL Group Replication是建立在已有MySQL複製框架的基礎之上，透過新增Group Replication Protocol協議及Paxos協議的實現，形成的整體高可用解決方案。與原有複製方式相比，主要增加了certify的概念，如下圖所示：

certify模組主要負責檢查事務是否允許提交，是否與其它事務存在衝突，如兩個事務可能修改同一行資料。在單機系統中，兩個事務的衝突可以透過封鎖來避免，但在多主模式下，不同節點間沒有分散式鎖，所以無法使用封鎖來避免。為提高效能，Group Replication樂觀地來對待不同事務間的衝突，樂觀的認為多數事務在執行時是沒有併發衝突的。事務分別在不同節點上執行，直到準備提交時才去判斷事務之間是否存在衝突。下面以具體的例子來解釋certify的工作原理：

在上圖中由3個節點形成一個group，當在節點s1上發起一個更新事務UPDATE，此時資料庫版本dbv=1，更新資料行之後，準備提交之前，將其修改的資料集(write set)及事務日誌相關資訊傳送到group，Write set中包含更新行的主鍵和此事務執行時的快照(由gtid_executed組成)。組內的每個節點收到certification請求後，進入certification環節，每個節點的當前版本cv=1，與write set相關的版本dbv=1，因為dbv不小於cv，也就是說事務在這個write set上沒有衝突，所以可以繼續提交。

下面是一個事務衝突的例子，兩個節點同時更新同一行資料。如下圖所示，

在節點s1上發起一個更新事務T1，幾乎同時，在節點s2上也發起一個更新事務T2，當T1在s1本地完成更新後，準備提交之前，將其writeset及更新時的版本dbv=1傳送給group；同時T2在s2本地完成更新後，準備提交之前，將其writeset及更新時的版本dbv=1也傳送給group。

此時需要注意的是，group組內的通訊是採用基於paxos協議的xcom來實現的，它的一個特性就是訊息是有序傳送，每個節點接收到的訊息順序都是相同的，並且至少保證半數以上節點收到才會認為訊息傳送成功。xcom的這些特性對於資料庫狀態機來說非常重要，是保證資料庫狀態機一致性的關鍵因素。

本例中我們假設先收到T1事務的certification請求，則發現當前版本cv=1，而資料更新時的版本dbv=1，所以沒有衝突，T1事務可以提交，並將當前版本cv修改為2；之後馬上又收到T2事務的certification請求，此時當前版本cv=2，而資料更新時的版本dbv=1，表示資料更新時更新的是一箇舊版本，此事務與其它事務存在衝突，因此事務T2必須回滾。

核心元件XCOM的特性

 

MySQL Group Replication是建立在基於Paxos的XCom之上的，正因為有了XCom基礎設施，保證資料庫狀態機在節點間的事務一致性，才能在理論和實踐中保證資料庫系統在不同節點間的事務一致性。

主要原因在於corosync無法滿足MySQL Group Replication的要求：

此外MySQL Group Replication對於通訊基礎設施還有一些更高的要求，最終選擇自研xcom，包括以下特性：

閉環(closed group)：只有組內成員才能給組成員傳送訊息，不接受組外成員的訊息。

訊息全域性有序(total order)：所有XCOM傳遞的訊息是全域性有序(在多主叢集中或是偏序)，這是構建MySQL 一致性狀態機的基礎。

訊息的安全送達(Safe Delivery)：傳送的訊息必須傳送給所有非故障節點，必須在多數節點確認收到後方可通知上層應用。

檢視同步(View Synchrony)：在成員檢視變化之前，每個節點都以相同的順序傳遞訊息，這保證在節點恢復時有一個同步點。實際上，組複製並不強制要求訊息傳遞必須在同一個節點檢視中。

總結

MySQL Group Replication旨在打造一款事務強一致性金融級的高可用資料庫叢集產品，目前還存在一些功能限制和不足，但它是未來資料庫發展的一個趨勢，從傳統的主從複製到構建資料庫叢集，MySQL也在不斷的前進，隨著產品的不斷完善和發展，必將成為引領未來資料庫系統發展的潮流。

恩墨學院隸屬於雲和恩墨（北京）資訊科技有限公司，致力於提供專業高水準的與大資料培訓服務，挖掘培養大資料與資料庫人才。恩墨學院提供包括個人實戰技能培訓、個人認證培訓、企業內訓在內的全方位大資料和資料庫技術培訓。ACE級別超強師資，配備專業實驗室，沉浸式學習與訓練，專業實驗室、配備專業助教指導訓練。能迅速融入專家圈子，業內資源豐富，迅速積累職場人脈。課程包括：班、Oracle 、Oracle OCP考試等。