基于gtid实现的mysql主从复制,半同步复制,组复制

MySQL主从复制

1.mysql主从复制原理：
从库有两个线程IO线程和SQL线程
1.从库的IO线程向主库的主进程发送请求，主库验证从库，交给主库IO线程负责数据传输;
2.主库IO线程对比从库发送过来的master.info里的信息，将binlog文件信息，偏移量和binlog文件名等发送给从库
3.从库接收到信息后，将binlog信息保存到relay-bin中，同时更新master.info的偏移量和binlog文件名
4.从库的SQL线程不断的读取relay-bin的信息，同时将读到的偏移量和文件名写道relay-log.info文件，binlog信息写进自己的数据库，一次同步操作完成。
5.完成上次同步后，从库IO线程不断的向主库IO线程要binlog信息
6.从库如果也要做主库，也要打开log_bin 和log-slave-update参数
2.配置读写mysql主从复制的步骤：
1.在主库与从库都安装mysql数据库
2.在主库的配置文件(/etc/my.cnf)中配置server-id 和log-bin
3.在登陆主库后创建认证用户并做授权。
4.在从库的配置文件(/etc/my.cnf)中配置server-id
5.登陆从库后，指定master并开启同步开关。
需要注意的是server-id主从库的配置是不一样的。
Server-id存在作用：
mysql同步的数据中是包含server-id的，而server-id用于标识该语句最初是从哪个server写入的。因此server-id一定要有的
Server-id不能相同的原因：每一个同步中的slave在master上都对应一个master线程，该线程就是通过slave的server-id来标识的；每个slave在master端最多有一个master线程，如果两个slave的server-id 相同，则后一个连接成功时，slave主动连接master之后，如果slave上面执行了slave stop；则连接断开，但是master上对应的线程并没有退出；当slave start之后，master不能再创建一个线程而保留原来的线程，那样同步就可能有问题；
在mysql做主主同步时，多个主需要构成一个环状，但是同步的时候有要保证一条数据不会陷入死循环，这里就是靠server-id来实现的；
安装mysql包：
场景描述：
主数据库服务器：172.25.64.1，MySQL已经安装，并且无应用数据。
从数据库服务器：172.25.64.2，MySQL已经安装，并且无应用数据。
主从服务器都要安装mysql

[root@server1 mysql5.7]#yum install 
mysql-community-client-5.7.17-1.el6.x86_64.rpm  
mysql-community-common-5.7.17-1.el6.x86_64.rpm 
mysql-community-libs-5.7.17-1.el6.x86_64.rpm 
mysql-community-libs-compat-5.7.17-1.el6.x86_64.rpm 
mysql-community-server-5.7.17-1.el6.x86_64.rpm -y

编辑主配置文件
[root@server1 mysql5.7]# vim /etc/my.cnf
log_bin = mysql-bin #[必须加 ]启用二进制日志
server-id = 1 #ip最后一段
read_only=1 #只读
datadir=/var/lib/mysql 从给定目录读取数据库文件
socket=/var/lib/mysql/mysql.sock # 为MySQL客户程序与服务器之间的本地通信指定一个套接字文件(Linux下默认是/var/lib/mysql/mysql.sock文件)
symbolic-links=0
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

#初始化
[root@server1 mysql5.7]# /etc/init.d/mysqld start
Initializing MySQL database:                                [  OK  ]
Installing validate password plugin:                         [  OK  ]
Starting mysqld:                                           [  OK  ]
[root@server1 mysql5.7]# /etc/init.d/mysqld restart
Stopping mysqld:                                          [  OK  ]
Starting mysqld:                                           [  OK  ]
[root@server1 mysql5.7]# /etc/init.d/mysqld stop
Stopping mysqld:                                          [  OK  ]

修改root密码：两种方法：
方法一：alter命令修改：

[root@server1 mysql5.7]# /usr/bin/mysqld_safe --skip-grant-tables 
#忽略安全检测
2018-08-07T21:19:08.220649Z mysqld_safe Logging to '/var/log/mysqld.log'.
2018-08-07T21:19:08.223438Z mysqld_safe Logging to '/var/log/mysqld.log'.
2018-08-07T21:19:08.249574Z mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
^Z
[2]+  Stopped                 /usr/bin/mysqld_safe --skip-grant-tables
[root@server1 mysql5.7]# mysql -u root
mysql> grant all privileges on *.* to 'root'@'localhost' identified by 'root' ;
#出现这个问题可以按以下操作执行；关闭只读权限
'root' with grant option; ERROR 1290 (HY000): The MySQL server is running with the --skip-grant-tables option so it cannot execute this statement #出现这个问题可以按以下操作执行；关闭只读权限
mysql> set global read_only=0;
Query OK, 0 rows affected (0.00 sec)

mysql> flush privileges;#刷新更改
Query OK, 0 rows affected (0.52 sec)

mysql> grant all privileges on *.* to 'root'@'localhost' identified by 'root' with grant option;
Query OK, 0 rows affected, 1 warning (0.11 sec)#给超级用户密码root

mysql> set global read_only=1;#打开只读权限刷新列表
Query OK, 0 rows affected (0.00 sec)

mysql> flush privileges;
Query OK, 0 rows affected (0.12 sec)

方法二：
在初始化过程中生成随机密码在日至中：

[root@server3 ~]# cat /var/log/mysqld.log | grep password#筛选初始化是数据库登陆密码
2018-08-08T00:50:47.201578Z 1 [Note] A temporary password is generated for root@localhost: ;FC0sbdTH*Ry
2018-08-08T00:51:12.819362Z 0 [Note] Execution of init_file '/var/lib/mysql/install-validate-password-plugin.I69WGQ.sql' started.
2018-08-08T00:51:13.054598Z 0 [Note] Execution of init_file '/var/lib/mysql/install-validate-password-plugin.I69WGQ.sql' ended.
2018-08-08T00:51:15.342121Z 0 [Note] Shutting down plugin 'sha256_password'
2018-08-08T00:51:15.342135Z 0 [Note] Shutting down plugin 'mysql_native_password'
2018-08-08T00:51:22.302406Z 3 [Note] Access denied for user 'UNKNOWN_MYSQL_USER'@'localhost' (using password: NO)
2018-08-08T00:52:48.445784Z 4 [Note] Access denied for user 'UNKNOWN_MYSQL_USER'@'localhost' (using password: NO)
修改root密码
[root@server3 ~]# mysql_secure_installation
Enter password for user root:**;FC0sbdTH*Ry** 

All done! #这里修改的root密码强度要求

1.主服务器创建用户：

[root@server3 ~]# mysql -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.Your MySQL connection id is 12
mysql> grant replication slave on . to repl@’172.25.30.%’ identified by ‘Redhat123*’;#串建一个复制用户身份repl 密码Redhat123*可以是172.25.30.*网段登陆
Query OK, 0 rows affected, 1 warning (0.39 sec)
测试创建用户是否可以登陆成功：

mysql> show master status;

server-id用于标识该语句最初是从哪个server写入的.
从服务器设置master：
从服务器设置主服务器用主服务器的专属pos和主服务器建立连接主服务器将操作传给从服务器上执行

mysql> change master to master_host='172.25.30.3',MASTER_USER='repl',master_password='Redhat123*',master_log_file='mysql_bin.000001',master_log_pos=1003;

mysql> start slave;
Query OK, 0 rows affected (0.03 sec)
mysql> show slave status\G;

错误提示：
如果设置master失败解决方法如下：

#这里报错是因为slave状态没有关我们得关闭slave才能对其进行设置
ERROR 3021 (HY000): This operation cannot be performed with a running slave io thread; run STOP SLAVE IO_THREAD FOR CHANNEL '' first.
mysql> stop slave;
Query OK, 0 rows affected (0.39 sec)

测试创建：主服务器：

在从服务器上show databases；#注意从服务器上只有只读权限;不能在从服务器上进行操作：

2.基于gtid实现的mysql主从复制：

主从服务器的mysql主配置文件都要进行修改：
[root@server3 ~]# vim /etc/my.cnf

gtid_mode=ON
enforce-gtid-consistency=true
[root@server3 ~]# /etc/init.d/mysqld restart

从服务器更改slave设置：

mysql> change master to master_host='172.25.30.3', master_user='repl',master_password='Redhat123*',MASTER_AUTO_POSITION=1;
Query OK, 0 rows affected, 2 warnings (0.41 sec)

mysql> start slave;
Query OK, 0 rows affected (0.02 sec)

测试 查看：
主服务器上面建立新的数据库：

从服务器上查看：

3.基于gtid实现的mysql半同步复制

小知识：
异步复制（Asynchronous replication）
MySQL默认的复制即是异步的，主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否已经接收并处理，这样就会有一个问题，主如果crash掉了，此时主上已经提交的事务可能并没有传到从上，如果此时，强行将从提升为主，可能导致新主上的数据不完整。

全同步复制（Fully synchronous replication）
指当主库执行完一个事务，所有的从库都执行了该事务才返回给客户端。因为需要等待所有从库执行完该事务才能返回，所以全同步复制的性能必然会收到严重的影响。

半同步复制（Semisynchronous replication）
介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到relay log中才返回给客户端。相对于异步复制，半同步复制提高了数据的安全性，同时它也造成了一定程度的延迟，这个延迟最少是一个TCP/IP往返的时间。所以，半同步复制最好在低延时的网络中使用。
半同步复制原理：

在gtid基础上安装插件：可以先看看目录下有没有该插件：半同步复制模式必须在主服务器和从服务器同时中开启，否则将会默认为异步复制模式。
半同步复制需要安装插件，而插件的位置如下：


安装插件之前查看plugins;中rpl_semi_sync_master 状态：

从服务器状态：

确保value为YES

主安装插件

mysql> install plugin rpl_semi_sync_master soname 'semisync_master.so'; 
Query OK, 0 rows affected (0.15 sec)

mysql> set global rpl_semi_sync_master_enabled = on;
Query OK, 0 rows affected (0.00 sec)

从安装插件：

从：同步安装插件可以执行命令也可以写配置文件中：
在从my.cnf中写入：
[mysqld]
plugin-load="rpl_semi_sync_slave=semisync_slave.so";
主#plugin-load="rpl_semi_sync_master=semisync_master.so”;

打开全局同步

mysql> set global rpl_semi_sync_slave_enabled = on;
Query OK, 0 rows affected (0.00 sec)
#重启服务：如果在slave端开启io线程后，会自动调转为半同步模式进行数据传输
关闭io线程 在master上再进行事务时会等待10s后从半同步状态转为异步。当第二次进行数据插入时会变成异步同步mysql> stop slave IO_THREAD;
Query OK, 0 rows affected (0.09 sec)

mysql> start slave IO_THREAD;
Query OK, 0 rows affected (0.00 sec)

在主服务器上会看到异步关闭开启同步日志：

设置成功两个服务器的状态：

主服务器同步设置开启

从服务器同步服务开启：

我们可以测试一下看看从服务器是不是半同步复制：
关闭slave；
在主服务器对mysql进行操作：

打开slave查看mysql有没有变化：

4.集群复制部署：

我们设置的集群mysql组可以有一个master;多个slave；但是这样master的压力会很大,它需要把binlog—>传递给每一个slave;这样如果是半同步延迟会很大;因此我们可以均摊压力让master的slave去当下一个slave的master传递binlog给他的slave
我们可以在slave1的配置文件：
打开参数：
log-slave-updates #当设置 log_slave_updates 时,你可以让 slave 扮演其它 slave 的 master。此时,slave 把 SQL 线程执行的事件写进行自己的二进制日志(binary log),然后,其它的 slave 可以获取这些事件并执行它,从而有效缓解master 的压力。
添加一个 slave2:

1. 由于 master 上已经有数据,而新加的 slave2 没有,必须在配置复制前同步数据。
1)在 master 上执行一下命令
mysql> FLUSH TABLES WITH READ LOCK;
#锁表
mysql> mysqldump --all-databases --lock-all-tables > backup.db
mysql> UNLOCK TABLES;
#表解锁
2)如果你仅使用 MyISAM 表,你可以使用 mysqlhotcopy 拷贝,即使服务器正在运行。
# mysqlhotcopy -u root -p westos mysql bakcup
2. 在 slave1 上加入以下设置:
# vi /etc/my.cnf
....
server-id=2
log-bin=mysql-bin
binlog-ignore-db=mysqlbinlog-do-db=test
log-slave-updates
....
# /etc/init.d/mysqld restart

log-slave-updates 的作用如下图所示：

5.并行复制：

并行复制（多线程复制）：
在salve1上面开启并行复制：
vim /etc/my.cnf

slave-parallel-type=LOGICAL_CLOCK
slave-parallel-workers=16
该参数不能设为1当设为1该服务只开启一个调度这样复制转发binlog会更慢延时更长，该参数表并行线程数
master_info_repository=TABLE
relay_log_info_repository=TABLE
relay_log_recovery=ON

可以看到进程列表：

查看操作mysqlbinlog -vv –base64-output=DECODE-ROWS mysql-bin.000001

Slave2状态判断参数：
1>Read_Master_Log_Pos —–读id
2>Exec_Master_Log_Pos——执行id
这两个参数保持一致
3>Seconds_Behind_Master
在master执行之后的延迟时间
异步复制—->dumper传输事件—–>slave(IO)接受事件——>回给dumper一个ack在该过程中master中已经执行了snyc到磁盘—–>如果收到了ack就执行commit否则不执行,这里在master中内存已经保存了执行的动作只不过没有公开给客户端，但是如果slave挂掉了就会导致两个库之间数据的不一致。
半同步复制—–>dumper传输事件—–>slave接收事件—–>回复ack给master的dumper；如果没有收到slave的ack就一直等待(因此我们设置rpl_semi_sync_master_timeout=无穷大否则超过这个时间就会变成异步复制,),更不会sync到磁盘，当受到slave的ack就会执行sync——>commit.但是这里的dumper不仅要发送事件还要接收ack会比较慢所以我们用了并行
普通的replication，即mysql的异步复制，依靠mysql二进制日志也即binary log进行数据复制。比如两台机器，一台主机(master)，另外一台是从机(slave)。

正常的复制为：事务一（t1）写入binlog buffer；dumper 线程通知slave有新的事务t1；binlog buffer 进行checkpoint；slave的io线程接收到t1并写入到自己的的relay log；slave的sql线程写入到本地数据库。 这时，master和slave都能看到这条新的事务，即使master挂了，slave可以提升为新的master。
异常的复制为：事务一（t1）写入binlog buffer；dumper 线程通知slave有新的事务t1；binlog buffer 进行checkpoint；slave因为网络不稳定，一直没有收到t1；master 挂掉，slave提升为新的master，t1丢失。
很大的问题是：主机和从机事务更新的不同步，就算是没有网络或者其他系统的异常，当业务并发上来时，slave因为要顺序执行master批量事务，导致很大的延迟。

为了弥补以上几种场景的不足，mysql从5.5开始推出了半同步。即在master的dumper线程通知slave后，增加了一个ack，即是否成功收到t1的标志码。也就是dumper线程除了发送t1到slave，还承担了接收slave的ack工作。如果出现异常，没有收到ack，那么将自动降级为普通的复制，直到异常修复。 我们可以看到半同步带来的新问题：
如果异常发生，会降级为普通的复制。 那么从机出现数据不一致的几率会减少，并不是完全消失。主机dumper线程承担的工作变多了，这样显然会降低整个数据库的性能。

在MySQL 5.5和5.6使用after_commit的模式下, 即如果slave 没有收到事务，也就是还没有写入到relay log 之前，网络出现异常或者不稳定，此时刚好master挂了，系统切换到从机，两边的数据就会出现不一致。 在此情况下，slave会少一个事务的数据。

随着MySQL5.7版本的发布，半同步复制技术升级为全新的Loss-less Semi-Synchronous Replication架构，其成熟度、数据一致性与执行效率得到显著的提升。

MySQL 5.7数据复制效率的改进主从一致性加强, 支持在事务commit前等待ACK
新版本的semi sync 增加了rpl_semi_sync_master_wait_point参数, 来控制半同步模式下主库在返回给会话事务成功之前提交事务的方式。 该参数有两个值：

AFTER_COMMIT（5.6默认值）master将每个事务写入binlog ,传递到slave 刷新到磁盘(relay log)，同时主库提交事务。master等待slave 反馈收到relay log，只有收到ACK后master才将commit OK结果反馈给客户端。
    AFTER_SYNC（5.7默认值，但5.6中无此模式）master 将每个事务写入binlog , 传递到slave 刷新到磁盘(relay log)。master等待slave 反馈接收到relay log的ack之后，再提交事务并且返回commit OK结果给客户端。 即使主库crash，所有在主库上已经提交的事务都能保证已经同步到slave的relay log中。因此5.7引入了after_sync模式，带来的主要收益是解决after_commit导致的master crash主从间数据不一致问题，因此在引入after_sync模式后，所有提交的数据已经都被复制，故障切换时数据一致性将得到提升。性能提升, 支持发送binlog和接受ack的异步化

旧版本的semi sync 受限于dump thread ，原因是dump thread 承担了两份不同且又十分频繁的任务：传送binlog 给slave ，还需要等待slave反馈信息，而且这两个任务是串行的，dump thread 必须等待 slave 返回之后才会传送下一个 events 事务。dump thread 已然成为整个半同步提高性能的瓶颈。在高并发业务场景下，这样的机制会影响数据库整体的TPS 。 为了解决上述问题，在5.7版本的semi sync 框架中，独立出一个 ack collector thread ，专门用于接收slave 的反馈信息。这样master 上有两个线程独立工作，可以同时发送binlog 到slave ，和接收slave的反馈。
性能提升, 控制主库接收slave 写事务成功反馈数量
MySQL 5.7 新增了rpl_semi_sync_master_wait_slave_count参数，可以用来控制主库接受多少个slave写事务成功反馈，给高可用架构切换提供了灵活性。 当master对应有两个slave要求收到两份ack才能进行sync—->commit，当count值为2时，master需等待两个slave的ack。

6.组复制

有时候只有一个master,我们只能在这个主服务器上进行操作其他服务器只能复制他的行为,这样master的压力就会很大,因此我们应用了组复制在并行复制的基础上进行了改进,即在集群中中的组成员都可以是master，都可以操作数据库,当他们操作数据库也会同步到其他节点,这样不仅提高了效益还实现了去中心化。
在master：和其他组成组复制是一种可用于实现容错系统的技术。复制组是一个通过消息传递相互交互的 server 集群。通信层提供了原子消息(atomic message)和完全有序信息交互等保障机制。 这些是非常强大的功能,我们可以据此架构设计更高级的数据库复制解决方案。
MySQL 组复制以这些功能和架构为基础,实现了基于复制协议的多主更新。复制组由多个 server成员构成,并且组中的每个 server 成员可以独立地执行事务。但所有读写(RW)事务只有在冲突检测成功后才会提交。只读(RO)事务不需要在冲突检测,可以立即提交。换句话说,对于
任何 RW 事务,提交操作并不是由始发 server 单向决定的,而是由组来决定是否提交。准确地
说,在始发 server 上,当事务准备好提交时,该 server 会广播写入值(已改变的行)和对应的
写入集(已更新的行的唯一标识符)。然后会为该事务建立一个全局的顺序。最终,这意味着所有 server 成员以相同的顺序接收同一组事务。因此,所有 server 成员以相同的顺序应用相同更改,以确保组内一致。在不同 server 上并发执行的事务可能存在冲突。 根据组复制的冲突检测机制,对两个不同的并发事务的写集合进行检测。如在不同的 server 成员执行两个更新同一行的并发事务,则会出现冲突。排在最前面的事务可以在所有 server 成员上提交,第二个事务在源 server 上回滚,并在组中的其他 server 上删除。 这就是分布式的先提交当选规则

主服务器在数据库操作有所不同它需要设置
set GLOBAL group_replication_bootstrap_group=on;
开启组成员之后需要关闭该服务：
set GLOBAL group_replication_bootstrap_group=off;
mysql初始化：

Mysql配置文件：
编辑mysql配置文件：

log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
server-id=1 #使用统一标识号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
 server 配置为使用唯一标识号 1,以启用全局事务标识符,并将复制元数据存储在系统表(而不是文件)中。 此外,它设置 server 打开二进制日志记录,使用基于行的格式并禁用二进制日志事件校验和。 

Server组复制的配置

transaction_write_set_extraction=XXHASH64
#server 必须为每个事务收集写集合,并使用 XXHASH64 哈希算法将其编码为
loose-group_replication_group_name="a6c1728a-9c38-11e8-b537-525400b0abb"
#告知插件,正在加入或创建的组要命名为uuid
loose-group_replication_start_on_boot=off
#指示插件在 server 启动时不自动启动组复制。
loose-group_replication_local_address= "172.25.30.3:24901"
#告诉插件使用 IP 地址 127.0.0.1 或本地主机,端口 24901 用于接受来自组中其他成员的传入连接server 在此端口上侦听组成员之间的连接。 此端口不能用于用户应用程序,它必须保留
looss_group_replication_group_seeds="172.25.30.1:24901,172.25.30.2:24901,172.25.30.3:24901"
#组成员相互连接的端口由 group_replication_local_address 配置的本地地址必须可供所有组成员访问
loose-group_replication_bootstrap_group= off
loose-group_replication_single_primary_mode=off
loose-group_replication_enforce_update_everywhere_checks=on
#告诉插件,当下面这些 server 需要加入组时,应该连接到这些主机和端口上访问他们。 这些就是种子成员,当此成员想要连接到组时使用,在申请加入时,server 先访问这些种子成员中的一个,然后它请求组重新配置以允许它加入组。 需要注意的是,此选项不需要列出组中的所有成员,而是当此 sever 需要加入该组时需要访问的 server 列表。
启动组的 server 不使用此选项,因为它是初始 server,因此它负责引导组。 第二个加入
的server 向组中的唯一成员申请加入,然后组得以扩容。 第三个加入的 server 可以向这两个 server 中的任意一个申请加入,然后组再次扩容。 后续 server 在加入时重复此过程。
loose-group_replication_ip_whitelist="172.25.30.0/24,127.0.0.1/8"
#组成员白名单这个必须写否则会踩雷,因为组存在一定的安全性否则是登陆不了的
#loose-group_replication_local_address每个组成员各自写自己的ip
#配置文件中的server-id也需要修改

登陆在数据库中设置参数：

mysql> ALTER USER root@localhost identified by 'Redhat123*';
Query OK, 0 rows affected (0.09 sec)
#修改root密码因为初始化第一次登陆必须修改密码
mysql> SET SQL_LOG_BIN=0;
Query OK, 0 rows affected (0.00 sec)
#关闭日志记录
mysql> GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%' IDENTIFIED BY 'Redhat123*';
Query OK, 0 rows affected, 1 warning (0.00 sec)
#创建具有 REPLICATION-SLAVE 权限的 MySQL 用户。 此操作不应记录到二进制日志中
避免将更改传递到其他 server 实例
mysql> reset master;
Query OK, 0 rows affected (0.18 sec)
#重置master,以免发生不必要的意外
mysql> SET SQL_LOG_BIN=1;
Query OK, 0 rows affected (0.00 sec)
# 打开日志记录
mysql> change master to master_user='rpl_user',MASTER_PASSWORD='Redhat123*' FOR CHANNEL 'group_replication_recovery';
Query OK, 0 rows affected, 2 warnings (0.38 sec)
# 使用 CHANGE MASTER TO 语句将 server 配置为,在下次需要从其他成员恢复其状态时,使用 group_replication_recovery 复制通道的给定凭据。 执行以下命令,将 rpl_user 和 rpl_pass 替换为创建用户时使用的值。
mysql> INSTALL PLUGIN group_replication SONAME 'group_replication.so';
Query OK, 0 rows affected (0.19 sec)
#安装组复制插件
mysql> START GROUP_REPLICATION;
Query OK, 0 rows affected (6.08 sec)
#START GROUP_REPLICATION 语句返回后,组就已启动
mysql> set GLOBAL group_replication_bootstrap_group=on;
Query OK, 0 rows affected (0.00 sec)

mysql> START GROUP_REPLICATION;
Query OK, 0 rows affected (1.34 sec)

mysql> set GLOBAL group_replication_bootstrap_group=off;
Query OK, 0 rows affected (0.00 sec)
#检测组中已经创建了一个成员并且具有唯一的标识符 ce9be252-2b71-11e6-b8f4-00212844f856 它是在线的并且在 myhost 侦听端口 24801 上的客户端连接
mysql> SELECT * FROM performance_schema.replication_group_members;

6.1添加第二个实例

依旧初始化mysql先为它创建配置文件。 该配置类似于用于 server s1 的配置,
需要修改server_id=2，loose-group_replication_local_address= "172.25.30.2:24901"
mysql> ALTER USER root@localhost identified by 'Redhat123*';
Query OK, 0 rows affected (0.09 sec)

mysql> SET SQL_LOG_BIN=0;
Query OK, 0 rows affected (0.00 sec)

mysql> GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%' IDENTIFIED BY 'Redhat123*';
Query OK, 0 rows affected, 1 warning (0.00 sec)

mysql> reset master;
Query OK, 0 rows affected (0.18 sec)

mysql> SET SQL_LOG_BIN=1;
Query OK, 0 rows affected (0.00 sec)

mysql> change master to master_user='rpl_user',MASTER_PASSWORD='Redhat123*' FOR CHANNEL 'group_replication_recovery';
Query OK, 0 rows affected, 2 warnings (0.38 sec)

mysql> INSTALL PLUGIN group_replication SONAME 'group_replication.so';
Query OK, 0 rows affected (0.19 sec)

mysql> START GROUP_REPLICATION;
Query OK, 0 rows affected (6.08 sec)
这里与 s1 上执行的那些步骤有一个区别,就是不执行 SETGLOBALgroup_replication_bootstrap_group = ON 
在启动组复制之前,因为该组已由 server s1创建和引导。
此时,server s2 只需要添加到已经存在的组中。
mysql> select * from  performance_schema.replication_group_members;

Server1一样的操作：
加入组后的状态：

测试：master：

组成员查看：

组成员操作：

其他成员查看：