mysql group replication

Posted 2020-08-23

Mysq基于原生复制及paxos协议的组复制技术，提供强一致数据安全保证，可实现高可用、容灾等环境，亦可多点读写、负债均衡，mysql group replication(MGR)是mysql5.7.17中GA的一个plugin：

 

一、 功能支持：

1. 数据一致性

2. 多master拓扑，可在任意节点读写

3. 故障检测，自动剔除故障节点，自动加入新节点

二、数据操作（DML）

1. 多点写入冲突

同时在不同节点更新同样条件的数据，根据事务执行进度判断谁先提交就允许谁执行，另外的做回滚操作

2. GRP在multi-primary模式时可以在任何一个节点做操作，但时在事务commit时会广播所有的节点，作用有两点

检查数据是否冲突

广播该事务数据到所有节点执行

三、结构操作（DDL）

1、 DDL语句为当前读写操作，不支持事务的原子性，无法做到冲突检查回滚等操作，因此GRP对DDL语句的支持只能自行校对一致性

四、GRP复制基础

1、 GRP一个新加入的节点(slave)时从现在的集群中随机选择某一个节点(master)同步数据，当master发送binlog到slave时会缓存该时间内的事务操作，同时slave也监听数据的变化，一直执行直到数据延迟为0，该方式和传统的master-slave无差别，都是利用binlog及GTID实现，但是由paxos协议通过专用的复制通道（group_replication_recover,group_replication_applier）完成，当master宕机slave会自动链接到另外一个节点，关闭已宕机节点的主从链接，由此看出GRP并不存在单点的问题，也不需要传统的链接切换技术支撑

2、 复制压缩，当单个事务产生的binlog数据量大于设置的阈值(group_replication_compression_threshold)GRP会启用压缩功能,在网络IO存在瓶颈时能有效减少网络占用30%-40%，但是对CPU消耗也会增加，该功能根据实际情况判定是否使用，默认该功能是超过1M的数据量就启用压缩，关闭只需设置该参数为0

3、 GRP在binlog中增加了view_id项，一个view_id唯一的表示一个view，一个view对应一个节点配置，确定该节点是否正常的处在RP中，view_id的变更只在节点加入或者移除RP时，view_id的组成由一个随机id和递增数据组成(view_id=14816973865257164:35)，随机id在节点加入RP时随机生成，固定不变，递增数字只要节点移除、加入操作一次就加一，view_id会同步到所有节点的binlog中。

五、GRP要求及限制

1、要求：

引擎必须为innodb,因为需事务支持在commit时对各节点进行冲突检查

每个表必须由有键，在进行事务冲突检测时需要利用主键值对比

必须开启binlog且为row格式

开启GTID，且主从状态信息存于表中（--master-info-repository=TABLE 、--relay-log-info-repository=TABLE），--log-slave-updates打开

一致性检测设置--transaction-write-set-extraction=XXHASH64

2、限制：

RP和普通复制binlog校验不能共存，需设置--binlog-checksum=none

不支持gap lock，隔离级别需设置为read_committed

不支持对表进行锁操作（lock /unlock table）,不会发送到其他节点执行 ,影响需要对表进行加锁操作的情况，列入mysqldump全表备份恢复操作

不支持serializable隔离级别

DDL语句不支持原子性，不能检测冲突，执行后需自行校验是否一致

不支持外键

最多支持9个节点

六、故障侦测及恢复

1. GRP故障侦测机制是在检测周期内无法收到A发送的信息，就会发起集群内所有节点的判定，如果多数节点都无法接受到A的信息，即判断A节点故障，自动从集群中剔除

2. 当集群剔除故障节点，现有的节点会自动重组为一个全新的集群，在故障节点恢复后不会自动加入集群，需手动执行命令加入集群

七、安装部署

1、 下载最新版5.7.17初始化，我这测试的是在同一服务器部署3个不同端口的服务，server_id也当然需要不一样的，集群节点自增采用server_id+7的方式增长，所以server_id只能设置为个位数

2、 配置文件

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_write_set_extraction=XXHASH64

loose-group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa" #集群名称

loose-group_replication_start_on_boot=off #是否随着服务启动集群

loose-group_replication_local_address= "127.0.0.1:3011" #集群本机端口，和服务端口不同

loose-group_replication_group_seeds= "127.0.0.1:3013,127.0.0.1:3012,127.0.0.1:3011" #集群包含的所有节点

loose-group_replication_bootstrap_group= off #是否设置为主节点，当创建集群时其他加入的节点都以该节点为目标加入集群

3、 启动三个服务执行GRP安装

Install plugin group_replication soname “group_replication.so”;

Set sql_log_bin=0; #不记录创建用户信息到binlog以防加入集群时冲突

Grant replication slave on *.* to ‘rpl_test’@’%’ identified by ‘rpl_test’;

Flush privileges;

Change master to master_user=’rpl_test’,master_password=’rpl_test’ for channel ‘group_replication_recovery’;  #GRP专用复制通道

重启mysql服务让配置文件的GRP配置信息生效，初始化时RP插件是未安装的，各配置项也不会生效

4、 创建GRP

Mysql –p 3001

Msyql> set global group_replication_bootstrap_group=1;

Msyql> start group_replication;

Mysql> set global group_replication_bootstrap_group=0;

3002和3003节点直接执行start group_replication; 前提必须把步骤3完成才行

5、 这样一个单master节点的简单集群就搭建完毕，5.7.17在performance_schema下新增了几个replication开头的表记录RP的运行状态等信息，可以从replication_group_members表查看当前集群节点状态，select * from global_status where variable_name like "%group%"可以查看谁是当前的master节点

八、multi-primary模式：

1、该模式启用需设置两个参数

group_replication_single_primary_mode=0  #这个参数很好理解，就是关闭单master模式

group_replication_enforce_update_everywhere_checks=1 #这个参数设置检查对RP又影响的参数在各个节点是否一致

2、 默认启动的都是单master模式，其他节点都设置了read_only、super_read_only这两个参数，需要修改这两个配置

3、 完成上面的配置后就可以执行多点写入了，多点写入会存在冲突检查，这耗损性能挺大的，官方建议采用网络分区功能，在程序端把相同的业务定位到同一节点，尽量减少冲突发生几率

九、备份恢复

    等percona针对GRP的备份工具出来之后再测吧，也可以自行cp测试，需要记录对应的GTID

十、总结

MRP虽然采用的是msyql原生的逻辑复制原理，但是采用了poaxs协议控制，增加了binlog的缓存及压缩功能，在从节点恢复时会缓存这段时间事务的变化，在事务提交时广播至所有节点做一致性检查，这保证了数据同步的安全性，但是也存在延迟，虽然能保证数据全部发送到所有节点，但并不是同样的执行进度，提供自动容错为高可用提供了方便性，relay_log由两个文件组成，recovery存放恢复时的数据，applier存放追加的数据，该插件才GA有待时间验证。

本文出自 “D调de默默” 博客，请务必保留此出处http://xiaozhong991.blog.51cto.com/2354914/1883620