MGR特點

（1）基於Paxos協議和原生複製，多數節點同意即可透過事務提交；

（2）具備高可用自動故障檢測，可自動切換；

（3）可彈性擴充套件，叢集自動的新增和移除節點；

（4）有單主和多主模式；

（5）支援多節點寫入，具備衝突檢測機制，可以適應多種應用場景需求。

MGR組複製是什麼

（1）主從複製是非同步複製

master事務的提交不需要經過slave的確認，slave是否接收到master的binlog，master並不care。slave接收到master binlog後先寫relay log，最後非同步地去執行relay log中的SQL應用到自身。由於master的提交不需要確保slave relay log是否被正確接受，當slave接受master binlog失敗或者relay log應用失敗，master無法感知。

（2）半同步複製

基於傳統非同步存在的缺陷，MySQL在5。5版本推出半同步複製。可以說半同步複製是傳統非同步複製的改進，在master事務的commit之前，必須確保一個slave收到relay log並且響應給master後（從庫收到併產生 relaylog 後會向主庫傳送一個 ACK 的資訊包，當主庫獲得這個包後，認為從庫已經獲得 relaylog）才能進行事務的commit。但是slave對於relay log的應用仍然是非同步進行的。

（3）組複製

基於傳統非同步複製和半同步複製的缺陷——資料的一致性問題無法保證，MySQL官方在5。7。17版本正式推出組複製（MySQL Group Replication，簡稱MGR）。

由若干個節點共同組成一個複製組，一個事務的提交，必須經過組內大多數節點（N / 2 + 1）決議並透過，才能得以提交。如上圖所示，由3個節點組成一個複製組，Consensus層為一致性協議層，在事務提交過程中，發生組間通訊，由2個節點決議（certify）透過這個事務，事務才能夠最終得以提交併響應。

引入組複製，主要是為了解決傳統非同步複製和半同步複製可能產生資料不一致的問題。組複製依靠分散式一致性協議（Paxos協議的變體），實現了分散式下資料的最終一致性，提供了真正的資料高可用方案（是否真正高可用還有待商榷）。其提供的多寫方案，給我們實現多活方案帶來了希望。

組複製脫離了傳統的主從模式結構，是一個具有容錯功能的叢集架構，在組複製的架構中，有多個 server成員構成，並且每個成員都可以獨立執行事務，也就意味著多寫的功能，但是所有的讀寫事務必須在衝突校驗完成後才能提交，如果是隻讀型的事務那麼會直接提交。當某個節點上發出一個讀寫的事務準備提交時，那麼這個節點就會向整個叢集開始廣播這次讀寫的變更和對應的一個校驗識別符號，然後會針對這個事務產生一個全域性的順序號，由於是有順序號的，所以叢集中的每個成員都會按照順序去執行事務的變更從而保證了資料的一致性。

如果在不同的 server 上執行了相同的操作，並且產生了事務衝突，那麼校驗機制就會做成相應的判斷，通常先提交的事務先執行，後提交的回滾。所以從某種程度上來說，組複製是一種偽同步複製模式。

組複製的模式

（1）單主模式

在單主模式下，組有一個設定為讀寫模式的單主 server。組中的所有其他成員被自動設定為只讀模式（超級只讀模式）。主伺服器通常是用於引導組的第一個 server，所有其他加入的 server自動從主伺服器同步並設定為只讀。

在單主機模式下，將禁用在多主機模式下部署的某些檢查，因為系統會強制在組中每次只有一個寫入server。例如，在單主模式下允許對具有外來鍵的表進行更改，而在多主模式下不允許。在主伺服器故障時，自動選主機制選擇下一個主伺服器。透過按字典順序（使用其 UUID）來排序剩餘的 server成員並選擇列表中的第一個成員來作為下一個主伺服器。

如果主伺服器從組中移除，則啟動主節點選擇程式，然後從組中的其餘 server 成員中選擇新的主節點。透過檢視新檢視，按照詞典順序將 server 的 UUID 進行排序並選擇第一個作為主節點。選擇了新的主節點後，它將自動設定為只讀，其他輔助節點仍然為輔助節點，因此也是隻讀。

（2）多主模式

多主模式，也就是所有節點都可以寫入，每個節點基本都一樣。

PXC和MGR的區別：

PXC事務需要在所有節點跑一下

MGR多數節點同意，即可執行

b。複製

PXC在複製上需要Gcache中快取

MGR直接寫binlog

c。新增節點

新增節點PXC支援mysqldumpxtrabackup

MGR直接整合複製克隆

d。網路中斷

網路中斷髮生時，PXC具有分割槽的表不可讀寫

MGR可讀不可寫

e。流控

MGR寫入變慢

PXC所有節點不可寫

f。跨平臺

跨平臺；PXC支援LinuxMGR支援所有平臺

g。DDL

當PXC在進行DDL時，為了保證節點資料一致，此時整個叢集拒絕寫操作，注意是叢集內所有的表寫操作均無法提供寫服務，但是讀操作可以正常進行。

MGR 採用innodb儲存引擎，支援線上DDL

單主搭建（5.7）

規劃主機：

我這裡用三臺虛擬機器：

192。168。168。101 3306

192。168。168。102 3306

192。168。168。103 3306

（1）配置host和IP的對映

在三臺主機上分別 vi /etc/hosts。

MySQL的組複製依然存在解析 host 的 bug，所以我們必須在所有節點內把 host和 ip 的對映關係配置完畢。

192。168。168。101 master1

192。168。168。102 slave2

192。168。168。103 slave3

（2）關閉防火牆

檢視centos7的防火牆：

停止firewall：

禁止firewall開機啟動：

（3）快速初始化3臺MySQL庫

（4）配置MGR引數

分別在三臺配置檔案my。cnf上新增，配置後重啟生效。

分別將三臺庫重啟：

（5）建立組複製使用者

（6）安裝組複製外掛

在3套庫上都安裝：

（7）啟動並引導組複製

在單主模式中我們需要預設的選擇一個節點作為主節點，並且使這個節點成為引導節點。

選擇在101主機上的MySQL中執行以下的命令：

SET GLOBAL group_replication_bootstrap_group=ON； 意思是開啟節點的引導模式。

START GROUP_REPLICATION； 意思是開啟同步。

SET GLOBAL group_replication_bootstrap_group=OFF； 在我們將節點一設定為引導節點後關閉。

啟動報錯，檢視日誌。

在3套庫上都需要執行，可以寫入配置檔案。

可以檢視到，改節點已經加入到叢集中 ONLINE。

在erro日誌中看到到節點 1 已經透過 MGR 的內部通訊管理 GCS 加入到節點中。

檢視是否是主節點，可以看到101主機的庫是主節點：

8。0版本可以直接透過表performance_schemaerformance_schema。replication_group_members檢視是否是主節點，在5。7中檢視是否主節點需要這樣查：

測試：

為了驗證組複製是否能做到加入的節點後自動同步，我們這裡可以在節點 1 上造一點資料。

這裡我建立了一些庫和一些表。

等節點 2 和節點 3加入組後觀察是否同步：

（8）節點2加入

2節點加入到叢集，且不是主：

如果是8。0的MGR，可以直接從這裡查到是否是主：

資料也自動同步過來了，驗證了組複製新加入的節點資料自動同步：

（9）節點3加入

3節點加入叢集，且不是主：

可以檢視，資料已經同步過來了，再次驗證了組複製新加入的節點資料自動同步。

注意：配置檔案沒有寫：

在5。7中，開始組複製之前，可以手動配置寫入：

當然如果不寫，預設是：

多主搭建

多主節點搭建基本和單主步驟一樣，只需要配置檔案my。cnf額外新增，本文以下示例為單主節點搭建，多主節點搭建亦相差無幾。

單主搭建（8.0）

如下為8。0的單主三節點MGR叢集：