# MySQl组复制

### 组复制部署

**环境准备**
至少需要3台服务器，每台服务器上已经完成MySQL 8.0安装

```
192.168.26.160 master
192.168.26.128 node1
192.168.26.130 node2
```

组复制可以以单主或多主模式运行，默认是单主模式，这里选取192.168.26.160（主机名master）作为单主读写服务器，其他2台为只读服务器。

**查询主库uuid**

3台机器配置文件中的uuid需要一样,在主库使用select uuid()查询,使用主库的uuid即可

```bash
mysql> select uuid();
+--------------------------------------+
| uuid()                               |
+--------------------------------------+
| a71de24e-0bae-11f0-af42-000c29649a9e |
+--------------------------------------+
1 row in set (0.00 sec)
```

**修改配置文件**

组复制的事务传递是基于GTID的，且与部分引擎不兼容，因此需要修改相应的参数内容。

修改3台机器配置文件,新增下列参数：

```bash
#----------------认证插件-----------------------
#8.0默认使用的认证插件需要ssl认证,这里修改了认证插件不使用ssl
default_authentication_plugin=mysql_native_password 

#----------------Storage_engine----------------
# 组复制的数据必须存储在事务型引擎中。在多主模式下，事务冲突监测的机制是乐观型，即先执行事务，再检测冲突。如果有冲突则所有的成员都必须回滚，因此无法执行回滚的非事务型的存储引擎和组复制不兼容，需要禁用。
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"

#----------------Replication----------------
server_id=1 #三台机器不一样
gtid_mode=on
enforce_gtid_consistency=on
binlog_checksum=none
log_bin=mysql-bin
log_slave_updates=on
binlog_format=row

#----------------Group replication----------------
plugin_load_add='group_replication.so'
group_replication_group_name="6afcf923-0ba5-11f0-8fad-000c29649a9e"
group_replication_start_on_boot=off   # 在MySQL启动时不会自动启动组复制
group_replication_local_address= "192.168.26.160:33061" #修改成每个节点的ip即可
group_replication_group_seeds= "192.168.26.160:33061, 192.168.26.128:33061, 192.168.26.130:33061"
group_replication_bootstrap_group=off # 设置是否引导组服务（即创建一个组），一定要设置为off，否则每次重启都会引导一个新组出来。
```

**重启服务**

重启服务并通过show plugins命令确认组复制插件已安装：

```bash
mysql> show plugins;
```

**设置分布式恢复服务的用户凭证**
当有新成员加入组复制时，会通过分布式恢复进程（Distributed Recovery Process）来同步数据。分布式恢复进程会先找一个数据的捐赠者（Donor）,并通过一个名为group_replication_reocvery的通道将捐赠者binlog中的事务发送给新成员。在这里需要一个授权用户凭证来建立分布式恢复的连接。这个用户在所有的组成员上都必须存在。

在主库执行下列命令创建连接用户：

```sql
set sql_log_bin=0;
create user repuser@'%' identified with 'mysql_native_password' by 'reppassword';
grant replication slave on *.* to repuser@'%';
grant connection_admin on *.* to repuser@'%';
grant backup_admin on *.* to repuser@'%';
flush privileges;
set sql_log_bin=1;
```

创建好用户后，将用户凭证指定为分布式恢复进程使用：

```sql
change master to master_user='repuser', master_password='reppassword' for channel 'group_replication_recovery';
```

**组复制引导**
第一次启动组复制称作引导，引导会创建一个组出来。通过group_replication_bootstrap_group参数来控制引导动作。引导组复制必须由单一服务器完成且只需要执行一次。如果group_replication_bootstrap_group设置为on，则每次重启都会创建出一个同名新组，这也是前面参数中将其设置为off的原因。

执行下列命令引导组复制：

```sql
set global group_replication_bootstrap_group=on;
start group_replication;
set global group_replication_bootstrap_group=off;
```

**注意**:只有在第一次启动组复制时，才需要设置group_replication_bootstrap_group，后续成员加入时都不能设置此变量，否则会产生经典的分布式系统问题 --- 脑裂（split brain）。

一旦start group_replication;语句成功返回后，组复制就成功启动了，可以通过下列语句确认引导结果：

------------------------------------------------

```sql
select * from performance_schema.replication_group_members;
```

查询结果显示member_state为online，member_role为primary，说明组复制已经引导成功了。

在主库运行一些事务,mysql8.0默认开始事务：

```sql
create database test;
use test;
create table t1(id int auto_increment primary key);
insert into t1 values(null);
insert into t1 values(null);
insert into t1 values(null);
commit;
```

然后可以通过show binlog events in '日志名';查看二进制日志中的内容,可以看到日志已写入二进制日志，此时主库可以作为捐赠者（Donor），可以将这些事务变更同步给后加入的成员。

**将其他成员加入组复制**
完成前面操作后，已经创建出了一个组，并且其中已有1台主库在运行了，下面需将另外两个成员也加入组复制。

新成员加入组时会有一个数据恢复的动作，如果加入时组内数据已经很大了，那么这个过程可能会耗费很长时间，并且如果主库purge过二进制日志，那么恢复会失败。此时应使用备份恢复工具（mysqldump/xtrabackup等）将待加入的成员数据状态还原至离主库较近的时间点，以缩短加入后的数据恢复时间。

本示例是全新环境，数据变更很少，且主库具有所有变更的日志，可以将新成员直接加入，由分布式恢复进程来同步数据。

所有从服务器重启服务并创建分布式恢复凭证

```
set sql_log_bin=0;
create user repuser@'%' identified with 'mysql_native_password' by 'reppassword';
grant replication slave on *.* to repuser@'%';
grant connection_admin on *.* to repuser@'%';
grant backup_admin on *.* to repuser@'%';
flush privileges;
set sql_log_bin=1;
change master to master_user='repuser', master_password='reppassword' for channel 'group_replication_recovery';
```

启动组复制，加入组

```sql
# 注意不需要再引导组了
mysql> start group_replication;  
mysql> select * from performance_schema.replication_group_members;
------+--------------+-------------+----------------+----------------------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+
| group_replication_applier | 0a7b9277-0bab-11f0-8d9d-000c29649a9e | master      |        3306 | ONLINE       | PRIMARY     | 8.0.41         | XCom                       |
| group_replication_applier | aad69d1c-0bab-11f0-bee6-000c29f67e93 | node2       |        3306 | ONLINE       | SECONDARY   | 8.0.41         | XCom                       |
| group_replication_applier | b0021552-0baa-11f0-bd9f-000c29b36e90 | node1       |        3306 | ONLINE       | SECONDARY   | 8.0.41         | XCom                       |
+---------------------------+--------------------------------------+-------------+-------
```

此时我们看到第二和第三个成员已经成功加入组复制，成员角色为secondary，状态为online。

### 组复制容错测试

为了测试组复制的容错，在主库上直接杀掉MySQL进程（非正常关闭），模拟服务器宕机。

```sql
killall mysqld
```

**观察角色切换**

在原来的从库上查询成员状态（kill命令在两次查询之间执行），注意此时服务器node1的角色自动从secondary变为primay，表示其被提升为新的主库：

```sql
select * from performance_schema.replication_group_members;
```

**原主库重新加入组复制**

将原主库重新启动，并加入组复制，注意此时宕机的主库将以从库的身份加入组复制（不会自动恢复主库身份），主库依然是上次切换的node1

```sql
#主库运行下列指令
start group_replication;
select * from performance_schema.replication_group_members;
```