原文地址：https://yq.aliyun.com/articles/175055?spm=5176.100239.bloglist.30.V4wyl5
db匠 2017-08-21 09:00:02 發表於： 阿里雲數據庫ApsaraDB
背景
爲了創建高可用數據庫系統，傳統的實現方式是創建一個或多個備用的數據庫實例，原有的數據庫實例通常稱爲主庫master，其它備用的數據庫實例稱爲備庫或從庫slave。當master故障無法正常工作後，slave就會接替其工作，保證整個數據庫系統不會對外中斷服務。master與slaver的切換不管是主動的還是被動的都需要外部干預才能進行，這與數據庫內核本身是按照單機來設計的理念悉悉相關，並且數據庫系統本身也沒有提供管理多個實例的能力，當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基於兩種複製模式都可以搭建高可用數據庫集羣，也能滿足大部分高可用系統的要求，但在對事務一致性要求很高的系統中，還是存在一些不足，主要的不足就是主從之間的事務不能保證時刻完全一致。
- 基於異步複製的高可用方案存在主從不一致乃至丟失事務的風險，原因在於當master將事務寫入binlog，然後複製給slave後並不等待slave回覆即進行提交，若slave因網絡延遲或其它問題尚未收到binlog日誌，而此時master故障，應用切換到slave時，本來在master上已經提交的事務就會丟失，因其尚未傳送到slave，從而導致主從之間事務不一致。
- 基於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複製模式。單主模式的集羣如下圖所示：
在多主模式下，每個節點都可以對外提供讀寫事務的服務。但在多主模式下，多個節點間的事務可能有比較大的衝突，從而影響性能，並且對查詢語句也有更多的限制，具體限制可參見使用手冊。多主模式的集羣如下圖所示：
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基礎設施，保證數據庫狀態機在節點間的事務一致性，才能在理論和實踐中保證數據庫系統在不同節點間的事務一致性。
Group Replication在通訊層曾經歷過一次比較大的變動，早期通訊層採用是的Corosync，而後來才改爲XCom。
主要原因在於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也在不斷的前進，隨着產品的不斷完善和發展，必將成爲引領未來數據庫系統發展的潮流。