利用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参数值是否被修改、是否互通；特别是在集群运行期间是否有修改，如果确认有修改，那么整个集群都需要重新启动，以便使用新得配置。

~
~
完毕！