Mysql Group Replication介绍

一、Mysql Group Replication简介

Mysql Group Replication(MGR)是一个全新的高可用和高扩展的MySQL集群服务。

高一致性，基于原生复制及paxos协议的组复制技术，以插件方式提供一致数据安全保证；

高容错性，大多数服务正常就可继续工作，自动不同节点检测资源征用冲突，按顺序优先处理，内置自动防脑裂机制；

高扩展性，自动添加移除节点，并更新组信息；

高灵活性，单主模式和多主模式。单主模式自动选主，所有更新操作在主进行；多主模式，所有server同时更新。

paxos协议，paxos是个分布式一致性协议，简单来说就是，它的事件需要多个节点共同参与，一个事件完成是指多个节点上均完成了自身的子事件(就让我门把这样的事件称为"分布式事件")，这样的分布式事件可以看作是多个子事件的复合。

二、数据库架构

多主模式（Mutil primary mode）和单主模式（Single primary mode）

下图为多主模式，3master+1slave，34为主库开启读写，31/33开启只读，37挂在34上做slave进行异步复制。

三、MySQL5.7版本 MGR部署

创建复制用户

mysql> grant replication slave,replication client on *.* to rep@'%' identified by '123456';

构建group replication集群

mysql> change master to master_user='rep',master_password='123456' for channel 'group_replication_recovery';

安装插件

mysql> install PLUGIN group_replication SONAME 'group_replication.so';

设置group_replication_bootstrap_group为ON是为了标示以后加入集群的服务器以这台服务器为基准，以后加入的就不需要设置。

mysql> set global group_replication_bootstrap_group=ON;

作为首个节点启动mgr集群

mysql> start group_replication;
mysql> set global group_replication_bootstrap_group=OFF;

添加实例（从库）

mysql> set global group_replication_allow_local_disjoint_gtids_join=ON;
mysql> start group_replication;

查看MGR状态

mysql> select * from performance_schema.replication_group_members;

基本配置

# Group Replication
server_id = 34
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

group_replication变量使用的loose-前缀是指示Server启用时尚未加载复制插件也将继续启动，根据自己配置修改

transaction_write_set_extraction = XXHASH64
loose-group_replication_group_name="01e5fb97-be64-41f7-bafd-3afc7a6ab555"
loose-group_replication_start_on_boot=off
loose-group_replication_local_address="127.0.0.1:13309"
loose-group_replication_group_seeds="127.0.0.1:13306,127.0.0.1:13307,127.0.0.1:13308"
loose-group_replication_bootstrap_group = off

相关参数

show variables like '%group_replication%';

流控制默认配置开启，默认配置，队列超过默认值会触发流控制，使整体集群性能受到影响。

四、MGR测试

MGR经过一段时间的测试，出现的问题大概总结为以下几点：

1．每次提交事务时尽量控制单次操作事务的数据量，减少大事物在其他节点check的时间和堵塞后面的操作带来的集群复制延迟，如事务回滚影响更大；

2．MGR集群环境部署对网络的依赖性较强，网络延时会导致整个集群性能的下降，集群内服务器尽量保持配置一致，集群内其中一服务器性能不好也会影响整个集群的整体性能；

3．DDL操作时，如操作的table有事物执行，在ddl时间内的所有的插入，更新和删除操作记录到一个日志文件，然后再把这些增量数据应用到相应的表上(等表上的事务完全释放后)，日志大小受innodb_online_alter_log_max_size参数限制，如写一直持续innodb_online_alter_log_max_size参数大小不好人为控制，会导致ddl执行失败；

4．Mysqldump会直接影响集群性能，xtrbackup因对磁盘io占用也会间接影响集群性能，建议备份节点考虑在mgr集群下挂载slave节点上执行备份；

5．版本升级，5.6在开启gtid后可直接升级至5.7.17并开启组复制模式；5.5版本则需要升级到5.6版本过渡一下才可升级为组复制模式。由于5.6、5.7版本上时间类型time,timestamp,datetime精度都支持到微秒精度，从5.5升级后带来的影响需要评估；

6．数据校验，现有工具Pt-table-checksum并不支持MGR集群的校验，仅可以对slave节点数据校验；

7．流量控制，当certifer_queue队列深度大于flow_crontrol_ certifer_threshold或者applier_queue队列深度大于flow_crontrol_ applier_threshold值时会触发流控制，触发流控制后写入会降低，这是为了避免更大的复制延迟，但是触发流控制后前端应用就会感觉可用率的下降，所以这个参数是个双刃剑，要根据实际生产环境设置，并且certifer_queue和applier_queue队列深度暂时没有监控项可监控，后期带来的运维问题也需要考虑；

8．MGR集群最多为9个节点，以5节点集群为例，集群内2个节点故障时，其余3个节点是可以继续提供服务的，但是当集群内有3个节点故障时，剩余2个节点就不能提供服务了，此时需要人工处理，如处理不当极容易发生脑裂现象。