MySQL MGR集群搭建
本文來自網易雲社區，轉載務必請註明出處。
本文將從零開始搭建一個MySQL Group Replication集群，包含3個節點。簡單介紹如何查詢MGR集群狀態信息。並介紹如何進行MGR節點上下線操作。先貼一份MySQL配置文件，如下：
explicit_defaults_for_timestamp=ON
# server configuration
datadir=/home/innosql/innosql/data/
basedir=/home/innosql/mysql/
port=3306
socket=/home/innosql/innosql/mysql.sock
#如果節點得hostname無法通過DNS正常解析，需要配置report_host
#report_host=10.200.128.67
max_allowed_packet=16M
max_connections=65536
log_error
#MGR要求和約束 詳見https://dev.mysql.com/doc/refman/5.7/en/group-replication-requirements-and-limitations.html
server_id=1
gtid_mode=ON
enforce_gtid_consistency=ON
master_info_repository=TABLE
relay_log_info_repository=TABLE
binlog_checksum=NONE
log_slave_updates=ON
log_bin=binlog
binlog_format=ROW
#super_read_only=ON
slave_parallel_type=logical_clock
slave_parallel_workers=16
slave_preserve_commit_order=ON
transaction_write_set_extraction=XXHASH64
#MGR參數配置 詳見 https://dev.mysql.com/doc/refman/5.7/en/group-replication-options.html
loose-group_replication_enforce_update_everywhere_checks = ON
loose-group_replication_single_primary_mode = OFF
loose-group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
loose-group_replication_start_on_boot=off
loose-group_replication_local_address= "mgr-node1.163.org:10086"
loose-group_replication_group_seeds= "mgr-node1.163.org:10086,mgr-node2.163.org:10086,mgr-node3.163.org:10086"
loose-group_replication_bootstrap_group= off
為了表示方便，我們將三個節點命名為mgr-node1、mgr-node2和mgr-node3。在mgr-node1上初始化MySQL，並啟動MySQL:
./mysql/bin/mysqld --defaults-file=/home/innosql/innosql/my-mgr.cnf --initialize-insecure
./mysql/bin/mysqld --defaults-file=/home/innosql/innosql/my-mgr.cnf &
登陸到mgr-node1客戶端，（可用通過mysql的prompt參數來設置客戶端顯示的提示信息），安裝group_replication插件：
mgr-node1>INSTALL PLUGIN group_replication SONAME ‘group_replication.so‘;
Query OK, 0 rows affected (0.01 sec)
我們已經在配置文件中包含了所有MGR所需的命令參數。比如組名稱group_replication_group_name，該參數必須為一個合法的UUID字符串。設置了本節點的MGR模塊通信地址group_replication_local_address，MGR集群的成員種子group_replication_group_seeds，該參數用於在異步故障恢復時選擇合適的數據貢獻者（donor）。在配置文件中，我們啟用了多主模式，即設置group_replication_single_primary_mode為off。對於同一個復制組的成員，必須確保他們各自的MGR相關配置不沖突，如group_replication_single_primary_mode、group_replication_enforce_update_everywhere_checks等。需要註意的是請在配置文件中將group_replication_bootstrap_group設置為off，該參數表示是否執行MGR復制組的初始化操作，通俗得說，如果該參數為on，那麽會新建一個MGR復制組。由於在我們的例子中，server1是第一個初始化節點，所以，我們動態開啟該參數，然後再啟動MGR：
mgr-node1>set global group_replication_bootstrap_group=on;
Query OK, 0 rows affected (0.00 sec)
mgr-node1>start group_replication;
Query OK, 0 rows affected (2.05 sec)
mgr-node1>set global group_replication_bootstrap_group=off;
Query OK, 0 rows affected (0.00 sec)
如上圖所示，在啟動MGR後，我們關閉了group_replication_bootstrap_group，確保下一次該節點啟動的時候不會再次進行初始化。導致復制組出現分裂。我們可以查詢當前MGR成員狀態：
mgr-node1>select * from replication_group_members;
+---------------------------+--------------------------------------+---------------------+-------------+--------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+---------------------+-------------+--------------+
| group_replication_applier | 2c4518a5-d4b4-11e7-a736-246e964083f0 | mgr-node1.163.org | 3306 | ONLINE |
+---------------------------+--------------------------------------+---------------------+-------------+--------------+
1 row in set (0.00 sec)
由於mgr-node1是第一個成員，所以members列表中僅有一個成員，可以看到起狀態是ONLINE，說明正常運行中。接下來創建一個賬號，權限為REPLICATION SLAVE ，該賬號為用於故障恢復的異步復制通道group_replication_recovery所用。MGR組復制所需的group_replication_applier通道不需要我們設置賬號和密碼。依次在server1客戶端執行如下SQL:
CREATE USER rpl_user@‘%‘;
GRANT REPLICATION SLAVE ON *.* TO rpl_user@‘%‘ IDENTIFIED BY ‘rpl_pass‘;
FLUSH PRIVILEGES;
基於該賬號設置group_replication_recovery復制通道，如下：
mgr-node1>CHANGE MASTER TO MASTER_USER=‘rpl_user‘, MASTER_PASSWORD=‘rpl_pass‘ FOR CHANNEL ‘group_replication_recovery‘;
Query OK, 0 rows affected, 2 warnings (0.01 sec)
上述就完成了第一個MGR節點初始化，接下來2個節點加入MGR執行的操作類似。但有個點需要指出：將第二個節點mgr-node2加入復制組前，除了確保group_replication_bootstrap_group處於關閉狀態之外，還需先執行CHANGE MASTER TO MASTER_USER=‘rpl_user‘, MASTER_PASSWORD=‘rpl_pass‘ FOR CHANNEL ‘group_replication_recovery‘再執行start group_replication。在mgr-node1加入組後，我們創建了復制用戶rpl_user，並執行了CHANGE MASTER TO，但其實並沒有發揮作用。而在mgr-node2，CHANGE MASTER TO才真正發揮作用，在start group_replication中，mgr-node2會根據配置文件中指定seeds參數找到mgr-node1，並使用rpl_user這個賬號連接到mgr-node1，拉取該節點的Binlog信息。所以mgr-node1上創建的用戶，是給其他節點加組或故障恢復用的，並不是給本節點用。
與官方手冊或網上的一些MGR搭建步驟不一樣，我們的步驟中並沒有在mgr-node2和mgr-node3上創建rpl_user用戶，因為該用戶可以通過Binlog從mgr-node1上復制到這兩個節點。這應該是更加簡潔的MGR搭建方式，不知為何官方分別在三個節點上創建rpl_user，為了避免復制沖突，又在創建前設置了session的sql_log_bin參數為off。新節點加入復制組的時候，其狀態為RECOVERING，如下：
mgr-node1>use performance_schema;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mgr-node1>select * from replication_group_members;
+---------------------------+--------------------------------------+---------------------+-------------+--------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+---------------------+-------------+--------------+
| group_replication_applier | 2c4518a5-d4b4-11e7-a736-246e964083f0 |mgr-node1.163.org | 3306 | ONLINE |
| group_replication_applier | 567f80c2-d65c-11e7-87a8-246e963b4310 |mgr-node2.163.org | 3306 | RECOVERING |
| group_replication_applier | fb08ecba-d65c-11e7-a74f-246e963b3e60 | mgr-node3.163.org | 3336 | RECOVERING |
+---------------------------+--------------------------------------+---------------------+-------------+--------------+
我們把加入組到狀態變為ONLINE分為三個階段，分別為本地恢復、全局恢復和緩存事務執行。本地恢復階段會檢查節點本地Relay Log中是否有可執行的Event，若有，則先執行完這部分Binlog。接下來進入到拉取本節點加入組之前復制組產生的而本節點沒有的Binlog信息並回放。最後是緩存事務執行階段，會將加入組之後產生的Binlog信息進行回放，這部分信息已事先緩存在本節點上。這三個節點回放Binlog/Relay Log所使用的復制通道分別是group_replication_applier、group_replication_recovery和group_replication_applier。
上面還有個問題，那就是如何區分第二和第三個階段。這就需要提到View_change_log_event，該類型的Binlog Event為MGR所用，用於記錄復制組中成員變化情況，每次成員加入或退出均會被記錄為一個新的Binlog Event，也就在Binlog中表達了一個組視圖（Group View）。回到本例，mgr-node2和mgr-node3加入組時，都會產生一個View_change_log_event，只需要在第二階段獲取Binlog時判斷是否讀到了當前視圖的View_change_log_event即可。
在復制組生命周期內，成員的加入或刪除都可以參考上述流程順利完成。但有一種特殊情況需要考慮。那就是如果萬一組中所有成員都下線了，第一個上線的節點就無法按照上述的恢復流程順利上線，因為第二階段不能順利完成，無法找到合適的種子拉取以前的Binlog信息。所以，此時需要特殊處理，即第一個節點起來執行start group_replication前需要設置group_replication_bootstrap_group為on。
MySQL為MGR提供了豐富的監控信息，基本上在performance_schema系統庫中，除了上述的replication_group_members外，還有replication_group_member_stats、replication_connection_status和replication_applier_status等。
本文主要介紹了如何搭建一個MGR集群，並未展開描述MGR的相關特性。感興趣的同學可以查閱MGR官方手冊，其中對MGR做了較為全面的介紹，是MGR入門的好幫手。
本文來自網易雲社區 ，經作者溫正湖授權發布。
網易雲免費體驗館，0成本體驗20+款雲產品！
更多網易研發、產品、運營經驗分享請訪問網易雲社區。
相關文章：
【推薦】 HBase原理–所有Region切分的細節都在這裏了
【推薦】 【工程實踐】服務器數據解析
MySQL MGR集群搭建