首页 > 代码库 > mysql group replication
mysql group replication
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
mysql group replication