内容簡要：
一、MGR特性
二、叢集架構
三、資料同步原理
四、性能分析
五、适用場景
六、高可用方案
（一）MGR是什麼
1.MGR的定義
MGR是具備強大的分布式協調能力，可用于建立彈性、高可用性、高容錯的複制拓撲的一個MySQL插件。
2.通訊協定
基于Paxos算法的GCS原子廣播協定，保證了一條事務在叢集内要麼在全部節點上送出，要麼全部復原。
3.組成員資格
MGR内部提供一個視圖服務，叢集節點之間互相交換各自的視圖資訊， 進而且實作叢集整體的穩态。
4.資料一緻性
MGR内部實作了一套不同僚務之間修改資料的沖突認證檢測機制。在叢集的所有節點當中進行一個沖突認證檢測，反之，通過沖突認證檢測的事務即可送出成功。
（二）示例
上圖是一個三節點的MGR執行個體叢集，Member1代表Primary節點，Member2、Member3代表Secondary節點。
當一個事務發起送出後，它會通過原子廣播協定分發到叢集其他Secondary節點。叢集的Secondary節點進行Binlog Event，通過沖突檢測之後，事務送出成功。在所有的Secondary節點送出成功之後，會在Primary節點進行送出。
反之，如果在Primary節點沖突認證檢測失敗，Secondary節點會丢棄這段事務對應的Binlog，Primary節點復原該事務。
MGR架構分為單主模式和多主模式，由多種插件組成。
（一）MGR插件組成
如上圖所示，MGR插件組成使用MySQL Server與API接口層以及若幹元件，最後由GCS（Group Communication System）協定封裝而成。
MySQL Server調用MGR插件是基于MySQL現有的主從複制，利用Row格式的Binlog和Gtid等功能實作的叢集架構。
API接口層複制基于MySQL Server互動的接口集，在邏輯上将MySQL核心與MGR插件隔絕開來。其他元件例如Capture元件，它是負責事務狀态在叢集内送出或是復原，以及通過Binlog event廣播到其他節點上進行的沖突認證檢測進行到哪個階段。Apply元件代表MGR叢集Secondary節點Binlog回放，Recovery元件代表進行崩潰恢複或叢集擴容時增量資料的應用。
（二）單主模式
單主模式叢集原理流程圖
ON表示單主模式，也是預設模式，OFF表示多主模式。
l 如上圖所示，在單主模式下（group_replication_single_primary_mode = ON）:
1．該變量在所有組成員中必須設定為相同的值，同一個組中，不能将成員部署在不同模式中。例如，一個成員配置為單主模式，另一個成員配置為多主模式。
2．該叢集具有一個設定為讀寫模式的主節點，組中的所有其他成員都設定為隻讀模式（superread-only = ON）；
3．讀寫節點通常是引導該組的第一個節點，加入該叢集的所有其他隻讀節點均需要從讀寫節點同步資料，并自動設定為隻讀模式。
（三）多主模式
多主模式叢集原理流程圖
l 在多主模式下（group_replication_single_primary_mode = OFF）:
1.所有節點不會區分Primary和Standby角色；
2.加入該叢集時，與其他組成員相容的任何節點都被設定為讀寫模式，并且可以處理寫請求， 即使它們在叢集内是并發執行的；
3.如果組複制中的某個節點停止接受寫事務，例如，在某個節點意外當機的情況下，可以将與 其連接配接的用戶端重定向或故障轉移到處于讀寫模式的任何其他健康的節點；
4.組複制本身不處理用戶端故障轉移，是以需要使用中間件架構（例如MySQL Router 8.0，代理，連接配接器或應用程式本身）來實作。
（一）同步原理示例
同步原理示例
如上圖所示，以一個三節點的MGR叢集為例。在單主模式下，當一個事務發起送出，它會通過原子廣播協定将事務伴随着Binlog Event廣播到其他Secondary節點上。在獲得叢集大多數節點同意之後，它會進行一個送出。如果通過沖突認證檢測，那麼該事務最終會在叢集當中送出。
如果在Secondary節點上面沒有通過沖突認證檢測，那麼Secondary節點丢棄該事務對應的Binlog，Primary節點復原該事務，
（二）沖突檢測原理
沖突檢測原理
l 如上圖所示，在沖突檢測時：
1.每個事務的Gtid Set和對應的主鍵Hash值組成事務認證清單，在每個節點中都維護這樣一個沖突檢測庫，這個庫在記憶體當中；
2.gtid set:标記資料庫的快照版本，事務送出前從gtid_execute變量中擷取該值；
3.事務送出前，資料庫中執行了的Gtid集合,随着Binlog中的Event通過原子廣播的方式分發到叢集的所有節點上進行事務沖突檢測。
（三）沖突檢測示例
如上圖所示，以T1與T2這兩條Update語句為例。
l 若T2修改的資料在沖突檢測資料庫中無比對記錄，則判定為通過沖突檢測認證；
l 若T2中的GTID SET包含了沖突檢測資料庫中相同主鍵值的GTID SET，則沖突認證檢測通過；
l 沖突認證檢測通過後，每個節點的沖突檢測資料庫按照如下規則變更：
1. 若在沖突檢測資料庫中無比對記錄，則向其中插入一條新的記錄。
2. 如果有記錄，則更新沖突檢測資料庫中的GTID SET值。
若T1修改的資料在沖突檢測資料庫中有比對到記錄，且T1的GTID SET不包括沖突檢測資料庫中的GTID SET，則判定為沖突檢測不通過。
注意：沖突檢測不通過時，不會更新認證資料庫裡的GTID SET。
（一）存在的問題
目前業記憶體在以下問題：
l MGR可確定僅在叢集中的大多數節點都已收到事務，并就并發發送的所有事務之間的相對順序達成一緻後才送出事務。相對順序意味着，在分發到Secondary節點之後，可以不按照Primary節點送出的順序進行送出，隻需保證和叢集的一緻性即可。
l 在流量小的時候不存在任何的性能問題。當流量突增時，如果叢集中某些節點的寫入吞吐量比其他節點少，尤其是小于Primary節點，則這些節點的資料和Primary節點的資料存在偏差。例如說在叢集當中，一個3節點的叢集，如果節點之間服務性能存在差異的話，則會存在性能問題。
l 在單主模式的叢集中，如果發生故障轉移，在新的Primary節點可以立刻接受寫入請求的情況下，則存在叢集内事務一緻性的問題。
舉例說明，當叢集擴容時，例如由3節點叢集擴容到5節點叢集：
l 無論采用Clone的方式還是用Xtrabackup做全量資料恢複後，都避免不了在叢集擴容期間産生的增量資料以二進制日志的方式來追平；
l 若新擴容的節點配置較低，寫入吞吐差，則新加入的節點很有可能一直處于Recover的狀态， 該節點很難達到Online的狀态。
（二）事務一緻性保證
在進行高可用切換之後，存在事務一緻性保證，這是由于Secondary節點和Primary節點存在追資料的過程，如果資料沒有追平，那麼業務資料可能會讀到舊的資料，使用者可以根據group_replication_consistency參數對應的可選值進行調整，總共有5個值如下：
1. EVENTUAL
開啟該級别的事務（T2），事務執行前不會等待先序事務（T1）的回放完成，也不會影響後序事務等待該事務回放完成。
2.BEFORE
開啟了該級别的事務（T2），在開始前首先要等待先序事務（T1）的回放完成，確定此事務将在最新的資料上執行。
3.AFTER
開啟該級别的事務（T1），隻有等該事務回放完成。其他後序事務（T2）才開始執行，這樣所有後序事務都會讀取包含其更改的資料庫狀态，而不管它們在哪個節點上執行。
4. BEFORE_AND_AFTER
開啟該級别等事務（T2），需要等待前序事務的回放完成（T1）；
同時後序事務（T3）等待該事務的回放完成。
5. BEFORE_ON_PRIMARY_FAILOVER
在發生切換時，連到新主的事務會被阻塞，等待先序送出的事務回放完成；
這樣確定在故障切換時用戶端都能讀取到主伺服器上的最新資料，保證了一緻性。
使用者根據不同的級别，根據業務上是讀多寫少，還是寫多讀少，或者是讀寫均衡的請求，不同的場景選擇不同的值即可。
（三）流控機制
1.流控機制的功能
l 性能的問題對應着解決方案，MGR的流控機制試圖解決以下問題：
1）叢集内節點之間不會相差太多的事務；
2）快速适應叢集内不斷變化的負載，例如叢集内的寫壓力暴增或叢集中增加更多的節點；
3）均分可用寫容量到叢集内的所有節點上；
4）避免減少吞吐量而造成資源浪費。
2.基本機制
l 流控機制存在兩個基本機制：
1）監控叢集内所有節點以收集有關吞吐量和隊列大小的一些統計資訊，以便對每個節點能承受的最大寫入壓力進行有根據的評估；
2）對叢集中的所有節點的并發寫能力時刻保持監控，一旦某節點的并發壓力超過了叢集中所有節點的平均 寫能力，就會對其執行流量控制。
3.基本隊列
流控機制存在兩個基本隊列：認證隊列和二進制日志應用隊列。
當其中一個隊列的大小超過使用者定義的門檻值時，就會觸發流量控制機制。
l 對于流量控制配置：
首先，需要選擇對誰配置流量控制，是對認證隊列、還是針對應用隊列、還是兩者都需要配置流量控制。然後，對需要配置流量控制的對象（認證隊列和應用隊列）設定流量控制門檻值。
4.流控過程
l 流控具體過程如下：
1）将根據上一階段延遲的事務數量逐漸減少10%，讓觸發限流機制的隊列減小到限流機制被觸發的門檻值之内， 待到恢複後，為避免在隊列大小超過門檻值時出現吞吐量的陡增，在此之後，每個時間段的吞吐量隻允許增長相同的10%；
2）目前的限流機制不會影響到觸發限流機制門檻值内的事務，但是會延遲應用超過門檻值的事務，直到本監控周期結束；
3)如果觸發節流機制的門檻值設定的非常小，部分事務的延遲可能會接近一個完整的監控周期。
在日常業務中，MGR高可用叢集存在如下經典适用場景：
1.彈性複制
需要非常靈活的複制基礎設施的環境，其中MySQL Server的數量必須動态增加或減少，并且在增加或減少Server的過程中，對業務的副作用盡可能少。例如，雲資料庫服務。
2.高可用分片
分片是實作寫擴充的一種流行方法。基于MGR實作的高可用分片，其中每個分片都會映射到一個複制組上（邏輯上需要一一對應，但在實體上一個複制組可以承載多個分片）。
3.替代主從複制
在某些情況下，使用一個主庫會造成單點争用。在某些情況下，向整個組内的多個成員同時寫入資料，多種模式可以避免單點争用，對應用來說可能伸縮性更強。
上圖為業内的一個常用的高可用方案。
通常在雲資料庫裡，一個三節點的MGR叢集本身不保證業務的寫入重定向，那麼在MGR叢集上面加一個讀寫分離的中間件Maxscale。
将源代碼重新編譯之後，會打開一個它自帶的保活機制，Maxscale會自動探測MGR叢集裡Primer節點狀态，如果發生高可用切換或者是目前的Primary節點當機之後，它會重新探測選取出來一個新的Primary節點，然後自動将業務寫請求重定向到新的Primary節點上。業務隻需要将Client端經過SQL解析連到Maxscale，然後經Maxscale做一個路由轉發，即可實作一個靈活的高可用。