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-node一、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切分的細節都在這裏了
【推薦】 【工程實踐】服務器數據解析