1. MGR背景
MySQL Group Replication 是MySQL官方提供的强一致性存储方案，可以很方便的提供多点写入，跨机房等功能。搭建MGR步骤：
MGR搭建
测试版本: Percona Server 5.7.19
2. 功能测试
测试机器信息
| alias | hostname | ip | port |
|---|---|---|---|
| rcdb1 | l-rc***db1.uc.cn2 | 10.****.189 | 3315 |
| rcdb2 | l-rc***db2.uc.cn2 | 10.****.196 | 3315 |
| rcdb3 | l-rc***db3.uc.cn2 | 10.****.221 | 3315 |
| rcdb4 | l-rc***db4.uc.cn2 | 10.****.234 | 3315 |
| collectdb3 | l-collect****db3.dba.cn8 | 192.****.202 | 3320 |
2.1 基本功能测试
| 测试项 | 结果 | 备注 |
|---|---|---|
| 新加入节点加入组后，数据是否一致 | ✔️ | |
| group内节点重启后加入，数据是否一致 | ✔️ | |
| group内节点，直接kill掉，重新加入后数据是否一致 | ✔️ | |
| 清理binlog后，新节点是否能加入 | 只要一个节点有新增节点所需的binlog就可以加入组，否则在尝试 group_replication_recovery_retry_count 次后报错，加入失败 | 节点加入组后无法执行 reset master;只能用purge binary logs to 'file';清理binlog |
2.2 加入脱离组
2.2.1 已有数据节点加入组
如果新增节点A落后数据很少，可以直接 START GROUP_REPLICATION; 加入组
如果新增节点A落后数据很多，则需要先选择任意一个组内节点作为master开启复制
CHANGE MASTER TO MASTER_HOST='ip',MASTER_PORT=port,MASTER_USER='replication',MASTER_PASSWORD='***',MASTER_AUTO_POSITION=1;
- 追上后直接START GROUP_REPLICATION; 加入组（如果直接加入组的话，会导致组fc）
- 查看是否成功加入组
SELECT * FROM performance_schema.replication_group_members\G;
查看 MEMBER_STATE 值是否为 ONLINE
2.2.2 通过备份加入组
- 使用备份数据做好数据(旧版本innobackupex不支持MySQL 5.7.19 使用的是公司打包的最新版 innobackupex version 2.4.7)
- 根据搭建MGR的步骤设置修改配置文件等（如果是跨机房需要修改group_replication_ip_whitelist,此参数默认只能同网段节点加入组，目前多点写入模式下无法通过备份加入组，但是可以在单主模式加入后，修改为多主）
配置group_replication_ip_whitelist
loose-group_replication_ip_whitelist='192.168.39.0/24,10.90.72.0/24'
- 根据xtrabackup_binlog_info 设置新增节点A的 gtid_purged (通过备份数据启动后的gtid值是落后的)
- 先选择任意一个组内节点作为master开启复制
CHANGE MASTER TO MASTER_HOST='ip',MASTER_PORT=port,MASTER_USER='replication',MASTER_PASSWORD='***',MASTER_AUTO_POSITION=1;
- 追上后直接START GROUP_REPLICATION; 加入组
- 查看是否成功加入组
SELECT * FROM performance_schema.replication_group_members\G;</pre>
查看MEMBER_STATE 值是否为 ONLINE
2.3 DDL和大事务操作影响
MGR进行alter操作是在主节点完成后，其他节点再开始执行
2.3.1 DDL对写入操作的影响
| 操作 | 状态 | 主节点 | 其他节点 | 备注 | |
|---|---|---|---|---|---|
| alter | |||||
| 主节点执行alter，其他节点未执行 | dml可以顺利执行 | 可以立刻同步主节点dml操作 | 无论是否为alter的表，都可以立刻执行，并同步 | ||
| alter 其他表也可以顺利执行 | 主节点完成后就开始同步 | alter一个表不会阻塞alter其他表 | |||
| 主节点完成alter，其他节点开始执行 | dml可以顺利执行 | 要等到alter操作执行完后，才同步dml操作 | 无论是否为alter的表，都可以立刻执行，但要等到完成alter操作后，才会同步dml | ||
| alter 其他表可以顺利执行 | 要等当前alter执行完后，才会执行 |
2.3.2 DDL中断的影响
| 操作 | 状态 | 主节点 | 其他节点 | 备注 |
|---|---|---|---|---|
| alter | ||||
| 主节点执行alter，其他节点未执行 | 不断对表进行插入操作 | 可以同步 | alter执行过程中不影响写入（不论修改表或者其他表）ctrl+C不会造成数据不一致 | |
| 主节点alter进行中，重启主节点 | 从读节点中选择一个作为主节点 | 主节点启动后可以加入group，数据一致 | ||
| 主节点alter进行中 读节点未执行 | 重启读节点 | 读节点重启后可以加入组并且数据一致 | ||
| 主节点alter完成， 读节点开始执行执行 | 重启读节点 | 读节点启动后正常加入组，数据一致（这个是等alter完成后读节点才完成关闭操作） | ||
| 主节点alter完成， 读节点开始执行执行 | kill读节点 | 重启后能够加入group数据一致（但是看文档说可能会有不一致的情况） |
2.3.3 qosc改表
| 操作 | 状态 | 主节点 | 其他节点 | 备注 |
|---|---|---|---|---|
| qosc alter | ||||
| 执行改表操作，不断插入数据 | ctrl+C | 无乱是否为修改表，都可以写入数据，清理trigger，临时表后可以再次qosc改表 | ||
| 读节点重启 | 加入group后数据一致 | |||
| 直接alter其他表 | 可以正常执行并同步 |
2.3.4 大事务影响
| 主节点session1 | 主节点session2 | 读节点 | 备注 |
|---|---|---|---|
| update big_table_1 set val1=1; （报错超过max_binlog_cache_size） | 写数据 | 对big_table_1操作被阻塞对其他表操作顺利执行，同步 | |
| update big_table_1 set val1=100 limit 10000000; （报错ERROR 3100 (HY000): Error on observer while running replication hook 'before_commit'.） | 写数据 | 锁不冲突的数据都能顺利执行同步,文档上说如果传输时间超过5s会导致失败 | |
| update big_table_1 set val1=100 limit 500000; | 与later一样，分为主节点执行阶段，读节点执行阶段： 主节点执行时，只要没有锁冲突的dml都可以执行并同步读节点执行阶段，因为要保证事务顺序一致，此时主节点的dml要等完成大事务后才会同步 |
3. 性能测试
复制线程为16
buffer_pool 为16G
机器为SSD
3.1 单点写入模式
image.png
image.png
3.2 多点写入
image.png
image.png
3.3 混合读写
集群三个节点
读写为10:4
14个读写操作为一个事务
单点写入
3.3.1 QPS
image.png
image.png
3.3.2 TPS
image.png
image.png
4. 基于MGR的InnoDB Cluster高可用
http://03bff331.wiz03.com/share/s/03L_cN2yvkX52KAoED0dgBk-2q1EdR14rA_02a95kh3ExGXn
5. MGR与PXC性能对比
MGR与PXC主要参数
复制线程为24
5.1 单点写入对比
image.png
image.png
5.2 多点写入
这个我测试了很多边，一直没想通为啥pxc可以在多点写入时性能那么好，感觉都没受到线程增加影响
mgr随着线程增加有明显的下降
image.png
image.png
5.3 混合读写
读写大概10:4 14个读写操作为一个事务
都为三个节点
image.png
image.png
综合上面对比可以发现，mgr 跟 pxc5.7 整体性能相近，单节点写入时mgr线程数较多时性能较佳，多节点写入时pxc5.7在线程数较多时性能较佳
