1. 為什么是MGR

MGR是MySQL Group Replication的縮寫，即MySQL組復制。

在以往，我們一般是利用MySQL的主從復制或半同步復制來提供高可用解決方案，但這存在以下幾個比較嚴重的問題：

因為上述幾個明顯的缺點，因此MySQL推出了全新的高可用解決方案 -- 組復制，這是本系列文章要着重介紹的新特性。

MGR是MySQL 5.7.17開始引入的，但隨着5.7版本逐漸退出歷史舞台（MySQL 5.7已於2020年10月起不再做大的功能更新，只有修修補補以及針對安全更新），更多MGR相關特性都只在MySQL 8.0上才有。

因此，如果線上還有基於MySQL 5.7版本的MGR環境的話，建議盡快升級、遷移到MySQL 8.0版本。進一步提醒，推薦MySQL 8.0.22及之后的版本，整體會更穩定可靠，也有些很不錯的新功能（不只是MGR方面的）。

2. MGR技術概要

MGR具備以下幾個特點：

MGR可以選擇單主（Single-Primary）模式
file

如上圖所示，一開始S1節點是Primary角色，提供讀寫服務。當它發生故障時，剩下的S2-S5節點會再投票選舉出S2作為新的Primary角色提供讀寫服務，而S1節點再達到一定超時閾值后，就會被踢出。

亦可選擇多主（Multi-Primary）模式（再次強烈建議選用單主模式）
file

如上圖所示，一開始S1-S5所有節點都是Primary角色，都可以提供讀寫服務，任何一個節點發生故障時，只需要把指向這個節點的流量切換下就行。

上述兩種架構模式下，應用端通過MySQL Router連接后端在MGR服務，當后端節點發生切換時，Router會自動感知，對應用端來說幾乎是透明的，影響很小，架構上也更靈活。

首先來個MGR的技術架構圖：
Group Replication Plugin Architecture

MGR是以Plugin方式嵌入MySQL，部署更靈活方便。

事務從Server層通過鈎子（hook）進入MGR API接口層，再分發到各組件層，在組件層完成事務Capture/Apply/Recover，通過復制協議層（Replication Protocol Logics）傳輸事務，最后經由GCS協調事務在各節點的最終一致性。

MGR節點間由組通信系統（GCS）提供支持，它提供了故障檢測機制、組成員角色管理，以及安全且有序的消息傳遞，這些機制可確保在各節點間一致地復制數據。這項技術的核心是Paxos算法的實現，在MySQL里稱之為XCom，由它充當MGR的通信引擎。

對於要提交的事務，組中的多數派節點必須就全局事務序列中給定的事務順序達成一致。各節點做出決定提交或中止事務的選擇，但所有節點都要做出相同的決定。如果發生網絡分區，導致節點間無法達成一致決定，則在網絡恢復前，MGR無法工作。

MGR支持單主和多主兩種模式，在單主模式下，各節點會自動選定主節點，只有該主節點能同時讀寫，而其他（從）節點只能只讀。在多主模式下，所有節點都可以進行讀寫。

相對於MariaDB Galera Cluster（以及基於此技術的Percona XtraDB Cluster，下面為了書寫方便，都統稱為PXC），個人認為MGR具備以下幾個優勢：

PXC的消息廣播機制是在節點間循環的，需要所有節點都確認消息，因此只要有一個節點故障，則會導致整個PXC都發生故障。而MGR則是多數派投票模式，個別少數派節點故障時，一般不影響整體的可用性。這也是PXC存在的最大問題。
PXC的節點間數據傳輸除了binlog，還有個gcache，這相當於是給MySQL又增加兩個黑盒子。而MGR則都是基於原生binlog的，沒有新增黑盒子，運行起來更可靠，需要排障時也更方便。
發生網絡分區時，整個PXC集群都不可用。而MGR則至少還能提供只讀服務。
PXC的流控機制影響更大，一旦觸發流控，所有節點都受到影響。而MGR觸發流控后，只會影響本地節點，不影響遠程節點。當然了，MySQL的流控做的也比較粗糙，在GreatSQL中進一步完善和優化。
執行DDL期間，整個PXC集群都不可同時執行DML，也就是說不支持Online DDL。而MGR是支持的，這也是很大的優勢。

相對於傳統主從復制（Replication），我認為MGR的優勢有以下幾點：

主從復制非常容易產生復制延遲，尤其是當表中沒有顯式主鍵時。而在MGR里，要求表一定要有主鍵（或是可用作聚集索引的非空唯一索引），避免了這個問題。
半同步復制中，一旦slave因為鎖或其他原因響應慢的話，也會導致master事務被阻塞。MGR是采用多數派確認機制，個別節點響應慢對Primary節點的影響沒那么大（不要選用AFTER模式）。
主從復制沒有類似MGR那樣提供事務數據的一致性保證。MGR自帶了事務數據一致性保障機制。

以上是我根據MySQL、MariaDB、Percona的資料整理得到的觀點，不一定准確和全面，有不完善的地方還請留言指正。