轉載自：https://www.cnblogs.com/shangxiaofei/articles/12502167.html
一、MGR架構原理簡介
狀態機復制
MGR本質上一個狀態機復制的集群。在狀態機復制的架構中，數據庫被當做一個狀態機。每一次寫操作都會導致數據庫的狀態變化。為了創建一個高可用的數據庫集群，有一個組件，即事務分發器，將這些操作按照同樣的順序發送到多個初始狀態一致的數據庫上，讓這些數據庫執行同樣的操作。因為初始狀態相同，每次執行的操作也相同，所以每次狀態變化后各個數據庫上的數據保持一致。
分布式的狀態機復制
事務分發器是一個單點，為了避免單點故障，可以采用分布式的狀態機復制。在分布式的狀態機復制中，有多個事務分發器，它們彼此互相通信。事務分發器可以同時接收事務請求，就像單個事務分發器同時接收事務請求一樣。從應用層來說，並發的事務發到同一個事務分發器和發到不同的事務分發器上效果是一樣的。事務分發器之間會互相通信，把所有的事務匯總、排序。最終，每個事務分發器上都有一份完整的排好序的事務請求。每個事務分發器只連接到一個數據庫上，並負責把事務請求依次發送到相連的數據庫上去執行，其就是一個分布式狀態機復制的模型了。
分布式的高可用數據庫
將分布式的事務分發模塊集成到數據庫系統中，就變成了一個分布式的高可用數據庫系統。用戶通過數據庫的用戶接口執行事務。數據庫收到事務請求后，首先交由事務分發模塊處理。事務分發模塊將事務匯總排序，然后依次交由數據處理模塊去執行這些事務。如果去掉內部的細節，就會發現這是一個非常簡潔的數據庫集群方案。MGR就是這樣一個分布式的高可用MySQL系統。
二、MYSQL高可用的背景
為了創建高可用數據庫系統，傳統的實現方式是創建一個或多個備用的數據庫實例，原有的數據庫實例通常稱為主庫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也在不斷的前進，隨着產品的不斷完善和發展，必將成為引領未來數據庫系統發展的潮流。