MySQL 5.7.17 Group Relication（組複製）搭建手冊

本博文介紹了Group Replication的兩種工作模式的架構。
並詳細介紹了Single-Master Mode的部署過程，以及如何切換到Multi-Master Mode。
當然，文末給出了Group Replication的配置要求和一些限制。


〇 結構介紹

在2016年12月釋出的5.7.17版本的MySQL，甲骨文宣佈Group Replication已經GA。

Group Replication（下簡稱GR）有兩個工作模式，分別為Single-Master Mode與Multi-Master Mode：


Single-Master Mode的failover圖：

只有primary成員可讀寫，而其他的節點為只讀，在primary成員發生故障時，將會有其他成員頂替成primary。


Multi-Master Mode的failover圖：


所有的成員均可讀可寫。


關於腦裂問題，可發現MySQL Group Replication與MongoDB Relicate Set有相似之處：
和MongoDB的Relicate Set相近，其讀寫庫類似於Primary，只讀庫類似於Secondary。

（下圖來自MySQL官方）


（下圖來自MongoDB 3.4 Manual）

---

〇 部署

測試例項數量：3臺
版本：MySQL 5.7.17

安裝（此處用的是二進位制包安裝）
mysql-5.7.17-linux-glibc2.5-x86_64.tar.gz


建立資料目錄及日誌目錄：


解壓二進位制包並將其設定為basedir：

1. mv mysql-5.7.17-linux-glibc2.5-x86_64.tar.gz /data/mysql57
   
2. cd /data/mysql57
   
3. tar zxvf mysql-5.7.17-linux-glibc2.5-x86_64.tar.gz
   
4. mv mysql-5.7.17-linux-glibc2.5-x86_64 mysql-basedir

〇 新增第一臺例項：
新增3306例項的配置檔案：


初始化3306例項datadir：

啟動3306例項：

透過MySQL Client進入第一個例項（密碼為空）

建立複製使用者與授權，並讓其作為group的第一個成員：


安裝GR外掛：


可以檢查一下是否安裝成功：


開啟第一個組複製：


檢查一下組複製成員，其中member_id就是@@server_uuid的值


新增測試資料：


〇 新增第二個例項（3307）
修改3307配置檔案，將3306改成3307，並且將loose-group_replication_local_address的埠從24901改成24902：


初始化3307例項：

啟動3307例項：

透過MySQL Client進入3307例項：

重複在3306例項的操作：


在3307例項上安裝GR外掛，開啟組複製：


檢查一下成員狀態：


過了一陣子再檢查，仍然是RECOVERING。


再過一陣子檢查，發現member_state被置為ERROR：


此時檢查3306例項的組複製情況，發現檢查不到另一個例項的資訊了：


開多一個終端，檢查3307例項的error log發現：


應該是解析的問題，修改hosts檔案，在末尾加上主機名：


重新操作3307例項：


檢查組複製狀態，發現兩個例項的狀態均為ONLINE了：


在3307上檢查一下同步狀態：


〇 新增3308例項：
修改3308配置檔案：


然後初始化並啟動3308例項：


同樣進入3308例項：

在3308例項上重複操作：


繼續重複操作，安裝GR外掛並啟動它：


最後再檢查一下組複製成員的狀態：


當然在3308例項上也已將3306的事務apply過來了：


root@localhost使用者在上述操作中為空密碼，可以給root@localhost加個密碼……
因為三個例項都在一個GR組裡，所以對3306例項操作就行了：


當然ALTER操作會被記錄到3306的binlog裡，並同步到3307和3308例項上。


可以檢視一下三臺例項的read_only和super-read-only值：


可以發現只有3306例項也就是第一個例項屬於可寫例項，而3307和3308均為read-only模式。
決定因素為第一個加入該GR組的成員，之後加入該GR組的均為ro，在該模式與MongoDB Replicate Set很相似。


當然如果要確定哪一個成員是primary，可以在三個成員中的任意一個執行：


至此，Group Replication預設的single-master mode已經搭建完畢。

---

〇 將Single-Master Mode修改為Multi-Master Mode

如果要將Single-Master Mode修改為Multi-Master Mode，也比較簡單。
考慮到此時的Primary成員是3306，並且假定3306例項在對外提供寫服務，我這邊的操作如下：


首先停掉兩個secondary的組複製，在3307和3308例項上操作：


再在3306例項上重複以上操作：


然後在3306上作為第一個成員啟動組複製：


在停啟組複製的過程中，3306例項仍對外提供服務，此處模擬修改：


再3307和3308兩個例項上分別開啟組複製：


並檢查3307和3308是否將3306的事務應用過來：
當然可以看到，在3306上做的修改，在3307和3308開啟組複製之後也已經同步過來了。


那麼再檢查一下3307和3308是否可寫：
顯然和Single-Master Mode不一樣的是，除了3306例項，另外兩個成員也就是3307和3308例項均為可寫成員了。
也就是所謂的Multi-Master Mode。


當然可以測試一下：
在3307例項上做insert，在3308例項上update，最後在3306上查詢：


至此，已經成功將Single-Master Mode修改為Multi-Master Mode。


P.S. 在多主模式中，已經不能透過下述SQL來查詢primary member是哪一臺例項了……雖然不明白為毛，可能在後續版本會改進？？？（猜測）
但總之在多主模式中，每一臺status為online的成員都是primary。

1. SELECT b.member_id, b.member_host, b.member_port
   
2. FROM performance_schema.global_status a
   
3. JOIN performance_schema.replication_group_members b
   
4. ON a.variable_value = b.member_id
   
5. WHERE a.variable_name= 'group_replication_primary_member';

總之……看起來很好用的樣子。



從零開始搭建Multi-Master Mode的GR同樣也很簡單，可以參考：
 


兩種工作模式在配置引數上的核心差別為：

---

〇 要求和限制

僅可用於InnoDB儲存引擎（需要事務的支援和行級鎖）
表必須有主鍵（建立無主鍵的表不會報錯，但在插入資料的時候會丟擲：ERROR 3098 (HY000): The table does not comply with the requirements by an external plugin.）
必須啟用GTID
必須開啟二進位制日誌，並且其格式必須為ROW（binlog_format=row）
衝突DDl、DML只能在同一成員上執行成功
在多主結構中，不完全支援外來鍵（單主結構中是沒有問題的）
不支援serializable的事務隔離級別
只支援IPv4，並且需要低延遲，高頻寬的網路環境
GR最大支援9個成員
複製資訊後設資料必須存在系統表（master-info-repository=TABLE、relay-log-info-repository=TABLE）
二進位制日誌checksums必須關閉（binlog-checksum=NONE）
不支援savepoint的使用

---

〇 參考文件：

MySQL 5.7 Reference Manual - 19.2 Group Replication 

馬楚成 - 使用群組複製實現MySQL高可用性 （）

mysqlha組文件 Docs ? Requirements and Limitations




作者微信公眾號（持續更新）