MySQL MGR集群搭建
本文來自網(wǎng)易云社區(qū)，轉(zhuǎn)載務(wù)必請注明出處。
本文將從零開始搭建一個MySQL Group Replication集群，包含3個節(jié)點。簡單介紹如何查詢MGR集群狀態(tài)信息。并介紹如何進行MGR節(jié)點上下線操作。先貼一份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
#如果節(jié)點得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參數(shù)配置 詳見?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
為了表示方便，我們將三個節(jié)點命名為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參數(shù)來設(shè)置客戶端顯示的提示信息），安裝group_replication插件：
mgr-node1>INSTALL PLUGIN group_replication SONAME 'group_replication.so';
Query OK, 0 rows affected (0.01 sec)
我們已經(jīng)在配置文件中包含了所有MGR所需的命令參數(shù)。比如組名稱group_replication_group_name，該參數(shù)必須為一個合法的UUID字符串。設(shè)置了本節(jié)點的MGR模塊通信地址group_replication_local_address，MGR集群的成員種子group_replication_group_seeds，該參數(shù)用于在異步故障恢復時選擇合適的數(shù)據(jù)貢獻者（donor）。在配置文件中，我們啟用了多主模式，即設(shè)置group_replication_single_primary_mode為off。對于同一個復制組的成員，必須確保他們各自的MGR相關(guān)配置不沖突，如group_replication_single_primary_mode、group_replication_enforce_update_everywhere_checks等。需要注意的是請在配置文件中將group_replication_bootstrap_group設(shè)置為off，該參數(shù)表示是否執(zhí)行MGR復制組的初始化操作，通俗得說，如果該參數(shù)為on，那么會新建一個MGR復制組。由于在我們的例子中，server1是第一個初始化節(jié)點，所以，我們動態(tài)開啟該參數(shù)，然后再啟動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后，我們關(guān)閉了group_replication_bootstrap_group，確保下一次該節(jié)點啟動的時候不會再次進行初始化。導致復制組出現(xiàn)分裂。我們可以查詢當前MGR成員狀態(tài)：
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列表中僅有一個成員，可以看到起狀態(tài)是ONLINE，說明正常運行中。接下來創(chuàng)建一個賬號，權(quán)限為REPLICATION SLAVE ，該賬號為用于故障恢復的異步復制通道group_replication_recovery所用。MGR組復制所需的group_replication_applier通道不需要我們設(shè)置賬號和密碼。依次在server1客戶端執(zhí)行如下SQL:
CREATE USER rpl_user@'%';
GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%' IDENTIFIED BY 'rpl_pass';
FLUSH PRIVILEGES;
基于該賬號設(shè)置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節(jié)點初始化，接下來2個節(jié)點加入MGR執(zhí)行的操作類似。但有個點需要指出：將第二個節(jié)點mgr-node2加入復制組前，除了確保group_replication_bootstrap_group處于關(guān)閉狀態(tài)之外，還需先執(zhí)行CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='rpl_pass' FOR CHANNEL 'group_replication_recovery'再執(zhí)行start group_replication。在mgr-node1加入組后，我們創(chuàng)建了復制用戶rpl_user，并執(zhí)行了CHANGE MASTER TO，但其實并沒有發(fā)揮作用。而在mgr-node2，CHANGE MASTER TO才真正發(fā)揮作用，在start group_replication中，mgr-node2會根據(jù)配置文件中指定seeds參數(shù)找到mgr-node1，并使用rpl_user這個賬號連接到mgr-node1，拉取該節(jié)點的Binlog信息。所以mgr-node1上創(chuàng)建的用戶，是給其他節(jié)點加組或故障恢復用的，并不是給本節(jié)點用。
與官方手冊或網(wǎng)上的一些MGR搭建步驟不一樣，我們的步驟中并沒有在mgr-node2和mgr-node3上創(chuàng)建rpl_user用戶，因為該用戶可以通過Binlog從mgr-node1上復制到這兩個節(jié)點。這應該是更加簡潔的MGR搭建方式，不知為何官方分別在三個節(jié)點上創(chuàng)建rpl_user，為了避免復制沖突，又在創(chuàng)建前設(shè)置了session的sql_log_bin參數(shù)為off。新節(jié)點加入復制組的時候，其狀態(tài)為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 |
+---------------------------+--------------------------------------+---------------------+-------------+--------------+
我們把加入組到狀態(tài)變?yōu)镺NLINE分為三個階段，分別為本地恢復、全局恢復和緩存事務(wù)執(zhí)行。本地恢復階段會檢查節(jié)點本地Relay Log中是否有可執(zhí)行的Event，若有，則先執(zhí)行完這部分Binlog。接下來進入到拉取本節(jié)點加入組之前復制組產(chǎn)生的而本節(jié)點沒有的Binlog信息并回放。最后是緩存事務(wù)執(zhí)行階段，會將加入組之后產(chǎn)生的Binlog信息進行回放，這部分信息已事先緩存在本節(jié)點上。這三個節(jié)點回放Binlog/Relay Log所使用的復制通道分別是group_replication_applier、group_replication_recovery和group_replication_applier。
上面還有個問題，那就是如何區(qū)分第二和第三個階段。這就需要提到View_change_log_event，該類型的Binlog Event為MGR所用，用于記錄復制組中成員變化情況，每次成員加入或退出均會被記錄為一個新的Binlog Event，也就在Binlog中表達了一個組視圖（Group View）。回到本例，mgr-node2和mgr-node3加入組時，都會產(chǎn)生一個View_change_log_event，只需要在第二階段獲取Binlog時判斷是否讀到了當前視圖的View_change_log_event即可。
在復制組生命周期內(nèi)，成員的加入或刪除都可以參考上述流程順利完成。但有一種特殊情況需要考慮。那就是如果萬一組中所有成員都下線了，第一個上線的節(jié)點就無法按照上述的恢復流程順利上線，因為第二階段不能順利完成，無法找到合適的種子拉取以前的Binlog信息。所以，此時需要特殊處理，即第一個節(jié)點起來執(zhí)行start group_replication前需要設(shè)置group_replication_bootstrap_group為on。
MySQL為MGR提供了豐富的監(jiān)控信息，基本上在performance_schema系統(tǒng)庫中，除了上述的replication_group_members外，還有replication_group_member_stats、replication_connection_status和replication_applier_status等。
本文主要介紹了如何搭建一個MGR集群，并未展開描述MGR的相關(guān)特性。感興趣的同學可以查閱MGR官方手冊，其中對MGR做了較為全面的介紹，是MGR入門的好幫手。
本文來自網(wǎng)易云社區(qū) ，經(jīng)作者溫正湖授權(quán)發(fā)布。
網(wǎng)易云免費體驗館，0成本體驗20+款云產(chǎn)品！
更多網(wǎng)易研發(fā)、產(chǎn)品、運營經(jīng)驗分享請訪問網(wǎng)易云社區(qū)。
相關(guān)文章：
【推薦】?HBase原理–所有Region切分的細節(jié)都在這里了
【推薦】?【工程實踐】服務(wù)器數(shù)據(jù)解析
總結(jié)
以上是生活随笔為你收集整理的MySQL MGR集群搭建的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： ssm(三)
- 下一篇： MySQL查询指定时间的数据