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;

如上圖所示，在啟動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

| 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切分的細節都在這裡了

【推薦】 【工程實踐】伺服器資料解析