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

恩墨學院發表於2018-01-10


小編寄語


主庫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節點,但並不等待傳送的結果,就會在儲存引擎中提交事務。

 Oracle 實戰

上圖是半同步複製(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實現,允許部分節點故障,只要保證半數以上節點存活,就不影響對外提供資料庫服務,是一個真正可用的高可用資料庫叢集技術。



Group Replication支援兩種模式,單主模式和多主模式。在同一個group內,不允許兩種模式同時存在,並且若要切換到不同模式,必須修改配置後重新啟動叢集。




在單主模式下,只有一個節點可以對外提供讀寫事務的服務,而其它所有節點只能提供只讀事務的服務,這也是官方推薦的Group Replication複製模式。單主模式的叢集如下圖所示:




Oracle 實戰


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


Oracle 實戰


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

Oracle 實戰

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



Oracle 實戰


在上圖中由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上沒有衝突,所以可以繼續提交。


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

Oracle 實戰

在節點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基礎設施,保證資料庫狀態機在節點間的事務一致性,才能在理論和實踐中保證資料庫系統在不同節點間的事務一致性。



Group Replication在通訊層曾經歷過一次比較大的變動,早期通訊層採用是的Corosync,而後來才改為XCom。




Oracle 實戰


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


1. MySQL支援各種平臺,包括windows,而corosync不都支援;
2. corosync不支援SSL,而只支援對稱加密方式,安全性達不到MySQL的要求;
3. corosync採用UDP,而在雲端採用UDP進行組播或多播並不是一個好的解決方案。



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



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


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


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


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


總結


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


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



來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/28530558/viewspace-2150011/,如需轉載,請註明出處,否則將追究法律責任。

相關文章