利用MySQL5.7.24對MGR配置進行官檔翻譯

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參數值是否被修改、是否互通；特別是在集羣運行期間是否有修改，如果確認有修改，那麼整個集羣都需要重新啓動，以便使用新得配置。

~
~
完畢！