MGR配置_5.7.24
一、MGR基本原則要求
1)表必須使用Innodb存儲引擎;
2)表必須有顯示的主鍵;
3)僅支持IPv4網絡;
4)網絡性能良好;成員服務器之間hostname互通、網絡延時低、目標端口開放。
A)關閉防火牆或開放後面設置得MGR通信端口:
# service iptables stop
# chkconfig --level 35 iptables off
B)如果不想更改服務器hostname,這可以使用report_host參數指定數據通信專用主機名稱,並在/etc/hosts中添加相應得地址解析。
# vim /etc/hosts
127.0.0.1 mgr21
這裏使用mgr21作爲MGR集羣內部通信使用的主機名。
注意:千萬不能寫成真實IP(192.168.0.21 mgr21),這樣修改完在服務器重啓後,主機名會被修改(至少Centos6裏會這樣)。
二、各個成員必須擁有的前提配置
開啓binlog ==> log_bin=ON
bin的ROW格式 ==> binlog_format=ROW
Slave開啓binlog ==> log_slave_updates=ON
GTID模式開啓 ==> gtid_mode=ON
複製信息庫 ==> master_info_repository=TABLE 和 relay_log_info_repository=TABLE
事務寫結合提取 ==>transaction_write_set_extraction=XXHASH64
多線程應用(建議)==>
slave_parallel_workers=N
slave_preserve_commit_order=1
slave_parallel_type=LOGICAL_CLOCK
三、MGR主要配置參數
[mysqld]
# server configuration
datadir=<full_path_to_data>/data/s1
basedir=<full_path_to_bin>/mysql-5.7/
port=24801
socket=<fullpathtosockdir>/s1.sock
#MySQL複製基礎參數(MGR的基礎)
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
transaction-isolation=READ-COMMITTED
#MGR配置(單主)
#如果不想更改服務器hostname,可以使用report_host參數指定數據通信專用主機名稱;主機名在多服務器間部署MGR是要特別注意的。
#添加前確保在各節點主機上的/etc/hosts中已添加相應得本機地址解析,如127.0.0.1 mgr21
report_host='mgr21'
transaction_write_set_extraction=XXHASH64
loose-group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa" #必須是正常得UUID,可在網上在線生成一個
loose-group_replication_start_on_boot=OFF
loose-group_replication_local_address= "127.0.0.1:24901"
loose-group_replication_group_seeds= "127.0.0.1:24901,127.0.0.1:24902,127.0.0.1:24903"
loose-group_replication_bootstrap_group=OFF #在引導成員上手動開啓配置,並在成員的配置文件裏明確寫入關閉
loose-group_replication_single_primary_mode=ON #ON單主模式 OFF多主模式
loose-group_replication_enforce_update_everywhere_checks=OFF #單主關閉 多主開啓
loose-group_replication_ip_whitelist="192.0.2.21/24,example.org,www.example.com/24" #設置MGR的IP白名單
loose-group_replication_transaction_size_limit=1048576 #組內允許的最大事務大小,這裏爲1M,需要根據實際情況設定;默認0爲不限制。
loose前綴的作用是在MySQL服務啓動過程中對那些應版本不兼容的參數,或者還未完全加載成功組建發出警告提示或忽略,
繼而不影響整個服務的啓動。
四、初始化實例
使用上面的配置文件,可以將3個節點一起初始(注意修改相應的端口、server_id、目錄等):
mkdir data
mysql-5.7.24/bin/mysqld --defaults-file=./s1_my.cnf --initialize-insecure --basedir=/usr/local/mysql-5.7.24 --datadir=/data/s1
mysql-5.7.24/bin/mysqld --defaults-file=./s2_my.cnf --initialize-insecure --basedir=/usr/local/mysql-5.7.24 --datadir=/data/s2
mysql-5.7.24/bin/mysqld --defaults-file=./s3_my.cnf --initialize-insecure --basedir=/usr/local/mysql-5.7.24 --datadir=/data/s3
五、啓動實例
初始化完成後,我們先啓動一個節點,作爲引導節點進行配置,其餘的節點後續(第八步)再逐個配置。
mysql-5.7/bin/mysqld_safe --defaults-file=/data/s1/s1.cnf &
六、配置、啓動MGR插件
1、創建分佈式恢復(group_replication_recovery異步)同步的複製賬號
SET SQL_LOG_BIN=0; ==>創建過程不能寫入binlog,避免複製給其他成員
CREATE USER rpl_user@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%';
FLUSH PRIVILEGES;
SET SQL_LOG_BIN=1;
2、配置數據恢復通道:
CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='password' FOR CHANNEL 'group_replication_recovery';
設置成功後在error.log中會發現相應的配置恢復通道的記錄信息,並在數據目錄下生成relay-log日誌文件:
<hostname>-relay-bin-group_replication_recovery.000001日誌和relay-log索引文件<hostname>-relay-bin-group_replication_recovery.index。
3、安裝、啓動MGR插件
1)在引導成員安裝組負責插件
INSTALL PLUGIN group_replication SONAME 'group_replication.so';
SHOW PLUGINS;
2)啓動MGR
SET GLOBAL group_replication_bootstrap_group=ON;
#注意:在啓動MGR後不要對主機IP等基礎配置做修改,否則新節點得加入可能會失敗;這是隻能重新啓動整個集羣,才能正常。
START GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group=OFF;
在啓動GROUP_REPLICATION過程中:
1)通過CHANGE命令啓用group_replication_applier數據應用通道;
2)然後爲group_replication_applier通道啓動SQL_thread線程,由它將記錄在applier日誌中上次未執行的事務應用到MySQL;
3)通過CHANGE命令啓用group_replication_recovery數據恢復通道;
4)爲group_replication_recovery啓動IO thread 線程,由它連接到primary節點獲取加入group時缺失binlog信息,保存在recovery日誌中(這些事務不會寫入applier日誌);
5)爲group_replication_recovery啓動SQL_thread線程,由它將保存在recovery日誌中的差距日誌應用到當前MySQL中;
6)當差距的事務被補齊後,group_replication_recovery上的I/O thread被停止,並退出group_replication_recovery通道;
7)進入正常通信-同步狀態(此時不再使用同步binlog日誌的方式);需要執行的新增事務將被記錄到本次使用的applier日誌中;
被記錄的每個事務前,都會加上本次MGR啓動時刻的時間以及新增GITD序號。
8)由SQL_thread線程將applier日誌中新增的事務應用到MySQL。
4、查看集羣狀態
SELECT * FROM performance_schema.replication_group_members; #查看成員狀態
select * from performance_schema.global_status where VARIABLE_NAME='group_replication_primary_member'; #查看當前主節點(單主模式)
或show global status like 'group_replication_primary_member';
select * from performance_schema.replication_connection_status \G; #查看應用通道(ON)、恢復通道(OFF)連接狀態
select * from performance_schema.replication_applier_status; #查看應用通道、恢復通道工作狀態
select * from performance_schema.replication_applier_status_by_worker; #查看應用線程、恢復線程工作狀態
七、插入測試數據
CREATE DATABASE test;
USE test;
CREATE TABLE t1 (c1 INT PRIMARY KEY, c2 TEXT NOT NULL);
INSERT INTO t1 VALUES (1, 'Luis');
SELECT * FROM t1;
SHOW BINLOG EVENTS;
八、加入新成員
1、配置啓動MGR
初始化、參數配置、啓動、MGR插件安裝和引導成員一樣,只是在啓動新成員加入組時不需要
操作 group_replication_bootstrap_group 配置,因爲組已經被先前的成員引導了,這裏直接啓動即可;
注意:因爲有時做初始化時避免不了節點上多執行了些命令,使得節點的GID大於了集羣內不得GID,但只要自己能確定數據時一致的就可以
在新加節點上使用如下命令來忽略這個問題;雖然日誌中仍然會有相應得錯誤提示,但集羣得建立不會受影響。或者直接reset master。
SET global group_replication_allow_local_disjoint_gtids_join=ON; #運行加入的新節點的GTID大於集羣內的GTID。
#啓動新節點已便加入MGR集羣
START GROUP_REPLICATION;
SET global group_replication_allow_local_disjoint_gtids_join=ON; #加入集羣后還原配置
2、查看組中成員:
SELECT * FROM performance_schema.replication_group_members;
3、查看數據同步
SHOW DATABASES LIKE 'test';
SELECT * FROM test.t1;
九、單主切換爲多主
在 GROUP_REPLICATION 運行的過程中是不允許切換的,所以要經過停止-->修改配置-->啓動的過程:
在單主基礎上修改如下參數即可:
loose-group_replication_single_primary_mode=OFF #ON單主模式 OFF多主模式
十、MGR特點及注意點
1、MGR使用限制
1)無法做複製事件校驗和,即binlog_checksum=NONE;
2)認證過程沒有考慮間隙鎖,因爲間隙鎖在Innodb之外不可用;
備註:除非應用程序依賴 REPEATABLE READ隔離級別,否則建議使用READ COMMITTED隔離級別。
3)認證過程不考慮表鎖(不考慮LOCK/UNLOCK語法);
4)不支持savepoint;
5)默認多主模式不支持SERIALIZABLE隔離級別,設置後拒絕事務提交;
6)多主模式下,不可在多個server上同時發起對同一個對象DDL操作。
在MGR多主模式中,多個server同時對同一行數據執行相同的DML語句,則遵循‘首次提交者勝出’(先下手爲強)原則。
禁止在不同Server上同時對同一個對象執行DDL語句中,同一時刻必須且只能在一個server上執行。因爲MySQL DDL的執行
不是原子性或事務性的,Server在位確保組內達成一致的情況下,會先執行並提交!!
7)多主模式下,不支持外鍵,即所有成員配置了 group_replication_single_primary_mode=OFF,這時不支持外鍵,單主無礙;
建議在多主模式下,動態設置 group_replication_single_primary_mode=ON 以避免未檢測到的衝突。
8)單主模式下,非Primary成員會被自動設置爲(超級)只讀模式;
2、單主模式自動選主機制:
在Primary服務器故障時,自動選主機制會按 server_uuid 參數值和 group_replication_member_weight 參數值來
選擇新的Primary服務器。
首先,根據 group_replication_member_weight 的值來排序,值最大的被選中;如果該值相同,則將server_uuid
值按字從小到大排序,第一個將被選中爲新的Primary服務器。新的Primary服務器將自動設置爲read-write;其他依
然是隻讀。
單主模式下查找Primary成員:
show global status like 'group_replication_primary_member';
show global variables like 'server_uuid'; 或者
select * from performance_schema.replication_group_members;
3、多主模式下沒有單主模式的概念,也就沒有必要使用選主程序了;因爲成員之間沒有什麼差異。
在新成員加入組時會自動、隨機分配一個在ONLINE狀態的成員作爲它的數據源節點;如果訪問失敗,則會重新分配一個;
如此往復直到連接成功,或者到達重試線上而停止(默認10次,由參數group_replication_recovery_retry_count決定)。
在重試過所有在線成員後 recovery 進程會休眠 group_replication_recovery_reconnect_interval 指定的時間,默認60秒。
4、如果同時有多個新成員加入,則會各自分配一個數據源,一個online的成員不會同時成爲多個新成員的數據源。
5、如果數據恢復過程中發生錯誤,則會更換數據源重新連接到新的數據源節點上。
6、自增長
在搭建group的時候,要注意每個實例中的auto_increment_increment跟auto_increment_offset的配置情況。
auto_increment_increment(自增長間隔):
在GROUP中合理範圍在1-9(因爲一個GROUP最多只能有9個組成員,太大會浪費自增值),GROUP中安裝的時候,默認爲7;其值等於group_replication_auto_increment_increment參
數值;
auto_increment_offset (自增步長):
則是等於server_id,但注意這裏有個規則:當 auto_increment_offset > auto_increment_increment 的時候,則忽略 auto_increment_offset 的設置,即第一個insert的自
增值從1開始,組內其他成員的初始值按照插入順序 1+n*組員個數。
例如GROUP有3個成員:A,B,C,serverid分別爲2243310,2243320,3423340;auto_increment_increment值爲3,則A先insert,C再insert,B最後insert,結果:初始值 A是1,B是9,C是6。
十一、網絡分隔
異常時要保證一個組內的大多數成員在一個網絡區域內,不然會導致仲裁丟失,集羣停止服務。
在多個新成員加入時,特別時加入的成員數大於等於現有成員數時,切記要一個個的加入,不可批量一起加入;
不然會出現集羣內半數成員處於非正常狀態(一半是新加入的),導致仲裁丟失;組對外停止服務。
十二、解除分隔
當組內半數以上的成員同時異常,雖然剩餘成員狀態正常,但整個組停止對外服務;
此時,要麼停止正常成員的服務,修復異常成員重新啓動組複製;要麼認爲強制由剩餘正常的成員組成新的組對外提供服務;
1)在各個正常成員上查看各自的組內通信地址:
SELECT @@group_replication_local_address;
2)選擇其中一個成員,配置新的成員關係(強制成員):
SET GLOBAL group_replication_force_members="127.0.0.1:10000,127.0.0.1:10001";
備註:
- 執行該命令要確保異常成員都已關閉,而不是形成了另外一個組,否則會人爲的導致了腦裂;
- 該命令會使正常成員使用不同的配置(各自生成新UUID)來解鎖舊組,繼而組成新的組;
3)查看組成員:
SELECT * FROM performance_schema.replication_group_members;
十三、組複製安全。
1、成員連接白名單
group_replication_ip_whitelist設置連接的白名單,默認只允許主機所在局域網網段連入;
要指定特定的範圍,可按如下操作:
mysql> STOP GROUP_REPLICATION;
mysql> SET GLOBAL group_replication_ip_whitelist="192.0.2.21/24,198.51.100.44,203.0.113.0/24,example.org,www.example.com/24";
mysql> START GROUP_REPLICATION;
2、SSL支持
SSL的支持-->瞭解
MGR組複製支持OpenSSL和yaSSL的安全協議。(需要生成密鑰)
數據恢復連接使用SSL配置:
1)在源端創建SSL安全賬戶
donor> SET SQL_LOG_BIN=0;
donor> CREATE USER 'rec_ssl_user'@'%' REQUIRE SSL;
donor> GRANT replication slave ON *.* TO 'rec_ssl_user'@'%';
donor> FLUSH PRIVILEGES;
donor> SET SQL_LOG_BIN=1;
2)在發起連接端生成SSL密鑰
new_member> SET GLOBAL group_replication_recovery_use_ssl=1;
new_member> SET GLOBAL group_replication_recovery_ssl_ca= '.../cacert.pem';
new_member> SET GLOBAL group_replication_recovery_ssl_cert= '.../client-cert.pem';
new_member> SET GLOBAL group_replication_recovery_ssl_key= '.../client-key.pem';
3)配置數據恢復通道
new_member> CHANGE MASTER TO MASTER_USER="rec_ssl_user" FOR CHANNEL "group_replication_recovery";
new_member> START GROUP_REPLICATION;
4)寫入配置文件中SSL相關配置:
[mysqld]
ssl_ca = "cacert.pem"
ssl_capath = "/.../ca_directory"
ssl_cert = "server-cert.pem"
ssl_cipher = "DHE-RSA-AEs256-SHA"
ssl_crl = "crl-server-revoked.crl"
ssl_crlpath = "/.../crl_directory"
ssl_key = "server-key.pem"
group_replication_ssl_mode= REQUIRED
十四、MGR性能配置可選項
1、GCT組通信線程:它負責從組和插件接收消息,處理仲裁成員數和故障檢測相關任務,發送保活信息,並處理server
成員和組之間的事務傳遞。GCT等待隊列中傳入消息然後進行處理,當等待超時時,它進入休眠狀態;可以通過以下方式
控制它的等待時間: SET GLOBAL group_replication_poll_spin_loops= 10000; 加長等待時間,在某些情況下比較有效,
因爲它可以代替CPU對GCT的上下文切換。
2、消息壓縮:MGR支持消息壓縮,在帶寬緊張時是有用的,默認開啓,閥值爲1000000 bytes,約1M。
通過以下方式修改壓縮閥值:
STOP GROUP_REPLICATION;
SET GLOBAL group_replication_compression_threshold= 2097152;
START GROUP_REPLICATION;
3、流量控制
MGR會確保事務僅在"組中的大多數成員接收到它,並且對併發發送的所有事務之間的相對順序達成共識"時提交。
當某個成員的吞吐量小於其他成員,會出現寫入量落後於組內其他成員。因此,MGR的使用流量控制機制來保證成員
間進度差異在允許的範圍。可以在認證隊列或二進制日誌應用隊列或者二者,在隊列大小超過閥值是,觸發節流機制;
可以使用如下參數配置:
group_replication_flow_control_applier_threshold
group_replication_flow_control_certifier_threshold
group_replication_flow_control_mode
閥值不可太小,否則會讓事務延遲處理,也不可太大,否則超出隊列範圍,加大了吞吐量壓力。
十五、MySQL企業備份(mysqlbackup)在MGR上的應用==>收費工具
mysqlbackup類似rman,它對MGR組成員的備份和備份單個實例沒什麼大的區別;基本步驟如下:
1)使用mysqlbackup根據源實例創建備份;
2)拷貝備份文件到目標實例服務器;
3)恢復數據到目標實例;
以單主模式爲例,操作如下:
1)查看組成員
SELECT member_host, member_port, member_state FROM performance_schema.replication_group_members;
2)執行備份(通常對非主成員,也可對Primary成員)
mysqlbackup --defaults-file=/etc/my.cnf --backup-image=/backups/my.mbi_`date +%d%m_%H%M` \
--backup-dir=/backups/backup_`date +%d%m_%H%M` --user=root -pmYsecr3t \
--host=127.0.0.1 --no-history-logging backup-to-image
3)拷貝備份文件到目標成員服務器
node2/backups# scp my.mbi_2206_1429 node1:/backups
4)恢復數據到目標成員實例(實例是關閉狀態)
mysqlbackup --defaults-file=/etc/my.cnf \
--backup-image=/backups/my.mbi_2206_1429 \
--backup-dir=/tmp/restore_`date +%d%m_%H%M` copy-back-and-apply-log
5)在多主模式下,爲了防止在成員的數據恢復過程中對外提供服務,配置文件可以進行如下配置:
group_replication_start_on_boot=OFF
super_read_only=ON
event_scheduler=OFF
6)啓動實例
7)重置MySQL的舊biglog文件、相關元數據信息;
mysql> RESET MASTER;
8)重置MySQL的relay log、元數據、複製通道等相關配置信息;
mysql> RESET SLAVE ALL;
9)使用備份產生的腳本設置gtid
mysql> SET SQL_LOG_BIN=OFF;
mysql> SOURCE datadir/meta/backup_gtid_executed.sql
mysql> SET SQL_LOG_BIN=ON;
10)配置分佈式恢復信息
mysql> CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='password' /
FOR CHANNEL 'group_replication_recovery';
mysql> START GROUP_REPLICATION;
11)當該實例加入組並完成數據恢復到最新時,歡迎之前做的臨時修改:
mysql> SET global event_scheduler=ON;
12)配置文件參數動態修改:
group_replication_start_on_boot=ON
super_read_only=ON
event_scheduler=ON
恢復結束。
十六、Binlog Event 多線程執行
Grou Replication 插件自動創建一個通道 group_replication_applier (channel) 來執行接收到的 Binlog Event;
當加入組時,Grou Replication 插件自動啓動 group_replication_applier 通道的執行線程(Applier Thread)
-- 手工調整這個通道執行線程
START SLAVE SQL_THREAD FOR CHANNEL 'group_replication_applier';
STOP SLAVE SQL_THREAD FOR CHANNEL 'group_replication_applier';
-- 基於主鍵的並行執行
SET GLOBAL slave_parallel_type = 'LOGICAL_CLOCK';
SET GLOBAL slave_parallel_workers = N;
SET GLOBAL slave_preserve_commit_order = ON;
Grou Replication 的 LOGCAL_CLOCK 與異步複製的算法不同,Grou Replication 併發策略的邏輯時間是基於主鍵計算出來的,
比異步複製基於鎖計算出來的邏輯時間的併發性要好很多。
基於主鍵並行複製特點
1)若兩個事務更新同一行,則要按順序執行,否則就可以併發
2)DDL 不能和任務事務併發,必須等待它前面所有事務執行完才能開始執行,後面的事務也要必須等等 DDL 執行完才能執行
爲什麼配置 slave_preserve_commit_order
併發執行時,不管兩個事務 Binlog Event 是不是同一 session 產生,只要滿足上面的特點就會併發,因此同一 session 裏的
事務可能被安排併發執行,會導致後執行的事務先被提交的情況,爲了保證同一個 session 的事務按照順序提交,必須配置此參數,
保證 Applier 上執行事務的提交順序和 源 MySQL 一致
十七、Paxos 協議優點
1)不會腦裂;
2)冗餘好,保證 Binlog 至少被複制超過一半成員,只要同時宕機成員不超過一半不會導致數據丟失;
3)保證只要 Binlog Event 沒有被傳輸到半數以上成員,本地成員不會將事務的 Binlog Event 寫入 Binlog 文件和提交事務,
從而保證宕機的服務器不會有組內在線不存在的數據,宕機的服務器重啓後,不再需要特殊處理就可以加入組。
十八、組複製相關視圖
SELECT * FROM performance_schema.replication_group_members;
SELECT * FROM performance_schema.replication_group_member_stats;
SELECT * FROM performance_schema.replication_applier_configuration;
SELECT * FROM performance_schema.replication_applier_status;
SELECT * FROM performance_schema.replication_applier_status_by_coordinator;
SELECT * FROM performance_schema.replication_applier_status_by_worker;
SELECT * FROM performance_schema.replication_connection_configuration;
SELECT * FROM performance_schema.replication_connection_status;
十九、常見疑問
1、MGR最多可包含幾臺MySQL Server?
最多9臺,之後拒絕加入;
2、組內Server如何通信?
通過點對點得TCP連接,且僅用於組內成員間得內部通信和消息傳遞。
3、相同負載下,和單純得複製相比,組複製是否需要更多得網絡帶寬和CPU?
因爲server間爲了保持組內同步和傳遞組內消息,需要完成更多複雜得工作,所有會佔用更多得內存和CPU資源;
此外,隨着組得變大,需要的通信帶寬自然也會高一點。但這很難量化。
4、在短暫的連接問題時,節點是否自動重新加入組?
成員一旦被剔除,則不會自動加入,需要手動加入。
二十、常見異常
1、新節點得GTID大於集羣內得GTID
2019-04-24T15:14:52.354558+08:00 0 [ERROR] Plugin group_replication reported: 'This member has more executed transactions than those present in the group. Local transactions: 77fb591c-65d9-11e9-ae2d-000c296ac0e9:1-3,
84055038-65d9-11e9-b540-000c297abe08:1,9aeaea1e-1321-4f1d-b3b3-7604d0ad472f:1-17 > Group transactions: 77fb591c-65d9-11e9-ae2d-000c296ac0e9:1,84055038-65d9-11e9-b540-000c297abe08:1,9aeaea1e-1321-4f1d-b3b3-7604d0ad472f:1-17'
2019-04-24T15:14:52.354604+08:00 0 [ERROR] Plugin group_replication reported: 'The member contains transactions not present in the group. The member will now exit the group.'
2019-04-24T15:14:52.354612+08:00 0 [Note] Plugin group_replication reported: 'To force this member into the group you can use the group_replication_allow_local_disjoint_gtids_join option'
日誌信息告訴我們可以使用group_replication_allow_local_disjoint_gtids_join參數,所以,在新節點上開啓該參數即可:
SET global group_replication_allow_local_disjoint_gtids_join=ON;
然後再重新啓動MGR服務:
START GROUP_REPLICATION;
2、防火牆未開放連接:
2019-04-23T23:38:07.880371+08:00 0 [Note] Plugin group_replication reported: 'XCom initialized and ready to accept incoming connections on port 33063'
2019-04-23T23:38:07.883599+08:00 0 [ERROR] Plugin group_replication reported: '[GCS] Error on opening a connection to 188.188.0.68:33061 on local port: 33063.'
2019-04-23T23:38:07.883714+08:00 0 [ERROR] Plugin group_replication reported: '[GCS] Error on opening a connection to 188.188.0.69:33062 on local port: 33063.'
地址不可達,需要確認一下防火牆是否開放、地址、端口是否配置正確。
3、節點間hostname不可達或集羣運行期間修改了IP地址或者集羣UUID不一致
2019-04-24T14:47:58.164328+08:00 0 [Note] Plugin group_replication reported: 'XCom initialized and ready to accept incoming connections on port 33063'
2019-04-24T14:48:28.166514+08:00 0 [ERROR] Plugin group_replication reported: '[GCS] Timeout while waiting for the group communication engine to be ready!'
2019-04-24T14:48:28.166593+08:00 0 [ERROR] Plugin group_replication reported: '[GCS] The group communication engine is not ready for the member to join. Local port: 33063'
2019-04-24T14:48:28.166975+08:00 0 [Warning] Plugin group_replication reported: 'read failed'
給出了加入集羣超時得錯誤,沒有具體得錯誤信息。
這時要確認IP、主機名、report_host參數值是否被修改、是否互通;特別是在集羣運行期間是否有修改,如果確認有修改,那麼整個集羣都需要重新啓動,以便使用新得配置。
~
~
完畢!