MySQL高可用解决方案（3）MGR集群部署与运维教程

一、MGR集群介绍

1、MGR工作原理

MGR全称是MySQL Group Replication（组复制），它是MySQL官方从5.7.17开始推出的一个高可用、高扩展性的分布式集群解决方案，如果说MHA为初代高可用解决方案、后续的各种第三方组件为2代，那么MGR可以说是属于第三代高可用解决方案，是未来的发展和使用趋势。

MGR包含了MySQL Shell（用于管理集群）、MySQL Router（读写分离及MGR状态感知）等组件。MGR由一组MySQL实例组成，每个实例都有一份完整的数据，可以实现数据的多点写入，并且采用类似Paxos算法的GCS协议进行同步，当事务产生时需要经过大多数节点认证并通过冲突检测后才能最终提交并执行（产生事务的节点属于本地节点，其他节点此时属于远端节点，远端节点会将认证通过的事务写入本地Relaylog，然后应用后写入Binlog才能执行），这样一来就解决了传统复制面临的单节点写入和数据一致性问题。除此以外，相比使用无损同步来保证数据一致性的做法，MGR性能更好（MGR会开启一个端口用于数据同步，而不是如复制一样使用MySQL服务的端口），所以MGR非常适合数据一致性要求极高的金融级业务场景。

2、MGR特性

相比Percona的PXC（基于MariaDB Galera Cluster改进），MGR有以下特点：

· 基于插件形式存在于MySQL服务中，不像PXC是打包了一个数据库

· PXC需要所有节点都确认后才能提交事务；MGR是多数节点确认即可提交事务，性能更好

· PXC基于Gcache，MGR基于binlog

· PXC触发流控后整个集群都受到影响，MGR只有本地节点受到影响

· PXC进行DDL操作夯住所有节点，MGR不会

· MGR支持单主和多主模式，单主模式下所有更新操作都是在主库执行（从库会被自动设置super read only，虽然可以手动修改但是不建议这样做），能自动探测主备状态，如果主库异常能自动进行切换操作，且能保持数据的一致性；多主模式下支持多节点写入，具备冲突检测机制

· MGR最多支持9个节点，故障节点数没有大于50%都可以正常工作，最大可故障主机=(节点数-1)/2

· 可自动增加和移除节点，新节点能自动同步其它节点的数据

· MGR节点间网络延迟尽量小，要避免跨网络部署

· MGR只支持InnoDB存储引擎，表必须有主键

· 主从模式需要为GTID，Binlog必须为ROW格式，且需要配置log_slave_updates

· 不要手动update mysql.user表，这样会导致secondary节点全部报错退出（因为手动update后没有flush privileges的动作）

· MGR对于大事务支持不友好，当事务大小超过143MB导致组成员无法在5秒内完成复制则可能会导致成员被驱逐

3、MGR选主顺序

· 所有节点都会参与选主

· 根据版本号进行优先选主，8.0.16以前的版本中主版本号越小的优先成为主节点，8.0.17开始按补丁版本排序

· 版本号一致的情况下会按照节点自身存在权重设置进行选举，权重高的优先选举（由group_replication_member_weight参数控制，默认50）

· 如果上述条件无法完成选主则按照server_uuid排序进行选举

4、MGR流控说明

为了保证各节点处理速度的基本一致，MGR基于配额（quota）对写事务进行了流控机制。认证队列和应用队列受流控影响，流控只针对本节点生效，不影响远程节点。如果是多主模式则各个PRIMARY节点平均分配流控的限额。需要注意不恰当的流控阈值会导致集群性能抖动，并且目前官方版本的流控算法不太完美，本身也会导致性能抖动，建议不要开启。

5、MGR故障检测

MGR各节点间会相互通信确认状态，当有节点超时未响应时由多数派节点判断是否失联。如果集群中多个节点处于Unreachable状态则集群会发生网络分区现象形成多个新集群（类似脑裂），发生网络分区时集群无法接受新的写事务请求。

二、MGR单主模式部署（至少三台服务器）（5.7版本下的MGR已经不再更新，推荐使用8.0版本）

1、所有节点在主从复制的基础配置上，增加以下配置内容

vi /etc/my.cnf
...
server-id=103306    #每台修改为不一样的id

#每个节点都要开启binlog用于记录从组中接收和应用的事务
log_slave_updates=1

#关闭binlog checksum
binlog_checksum=none

#必须小写表名
lower-case-table-names=1

#开启全局事务ID
gtid_mode=on
enforce_gtid_consistency=1
binlog_gtid_simple_recovery=1

#配置MGR插件和相关参数，loose前缀表示若MGR插件未加载，仍然启动MySQL
plugin_load="group_replication=group_replication.so"    #安装MGR插件，重启MySQL服务前一定要先安装好插件，否则配置文件无法通过
transaction_write_set_extraction=XXHASH64    #事务算法
loose-group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"  #GROUP组名，UUID格式，可以select uuid()生成，各节点保持一致
loose-group_replication_start_on_boot=off  #在启动mysql时是否自动启动组复制
loose-group_replication_local_address="192.168.94.11:33061"  #节点自身IP和端口，这里的端口用于集群内部通信，不是MySQL提供服务的端口
loose-group_replication_group_seeds="192.168.94.11:33306,192.168.94.12:33306,192.168.94.13:33306"   #种子节点的IP和端口，新节点加入集群时要与种子节点通信，而启动集群的第一个节点不需要做该配置
loose-group_replication_bootstrap_group=off    #是否作为集群引导者，建议关闭。通常是在集群第一个节点手动启动引导，集群启动后就要关闭该选项
group_replication_single_primary_mode=on      #是否启动单主模式，如果启动则本节点是主库，提供读写，其他实例仅提供读


#MGR性能配置
group_replication_flow_control_mode=DISABLE           #流控设置，默认为QUOTA，由于判断机制不太准确，并且性能损耗严重，建议DISABLE     
#group_replication_enforce_update_everywhere_checks=on  #多主模式严格一致性检查开关，该变量是组范围的，单主模式所有节点必须都关闭，多主模式要么全部开启要么全部关闭
#group_replication_flow_control_period=60            #流控检测频率，默认是1秒
#group_replication_flow_control_applier_threshold=25000     #触发流控的待执行队列长度，即replication_group_member_stats表里的COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE
#group_replication_flow_control_certifier_threshold=25000    #触发流控的待认证队列长度，即replication_group_member_stats表里的COUNT_TRANSACTIONS_IN_QUEUE 
#group_replication_transaction_size_limit=150000000       #单个事务大小上限，这里是150M
#group_replication_communication_max_message_size=10M      #将大事务切分成指定大小的小事务
#group_replication_message_cache_size=1G               #节点被踢出集群前缓存在本地内存中的数据大小，默认1G，并发事务高的话可以调大该值，如果物理内存很小可以调低，避免OOM
#group_replication_exit_state_action=READ_ONLY       #节点退出集群后进入只读模式，避免被意外修改数据导致无法重新加入集群
#group_replication_unreachable_majority_timeout=0         #发生网络分区时少数派节点离开集群的时间，建议设置为0不退出，避免分区导致少数派数据不一致
#group_replication_consistency=EVENTUAL      #事务一致性保障设置，默认EVENTUAL表示事务执行前不需要等待积压事务执行完毕，性能最好，单主模式下基本适用；BEFORE表示事务在应用前需要等待积压事务处理完毕；AFTER表示所有写事务需要等待所有节点确认，如果一个节点故障会导致整个集群不可用，所以不太推荐

2、每个节点创建组复制用户，并且加入MGR复制通道

mysql > set sql_log_bin = 0;  #避免下面的语句写入到binlog，导致已有这些账号的节点出现主从异常（新集群可以忽略这步）
mysql > grant replication slave on *.* to 'repl'@'192.168.%' identified by '123456'
mysql > grant replication slave on *.* to 'repl'@'localhost' identified by '123456'
mysql > change master to master_user='repl',master_password='123456' for channel 'group_replication_recovery'  #channel是通道的固定名字

3、选择一个节点作为引导节点，创建并启动集群

mysql > set global group_replication_bootstrap_group=on;  #初始化集群，选择一个节点执行即可
mysql > start group_replication  #启动集群
mysql > set global group_replication_bootstrap_group=off;

4、将其它节点加入集群，在启动MGR后会自动加入loose-group_replication_group_name所指定的GROUP，每个节点之间最好添加hosts相关配置，这样查看集群状态的时候MEMBER_HOST一列才能显示正确信息

start group_replication 

5、通过replication_group_members表检查MGR集群状态，如果状态都正常的话可以在不同节点新增数据进行测试，看是否正常同步到其它节点

mysql > select * from performance_schema.replication_group_members  #检查MGR集群状态

6、通过replication_group_member_stats表查看MGR队列情况，该表对于监视组中成员性能很重要。比如某节点的队列总是与其它成员差距较大，意味着该成员存在延迟，没有与其它节点保持同步。根据这些信息就需要决定是否从组中删除该成员或者延迟处理该组其它成员上的事务以减少排队事务的数量。此信息还作为流控触发标准

mysql > select * from performance_schema.replication_group_member_stats;  
# COUNT_TRANSACTIONS_IN_QUEUE   #等待被检查确认的远程事务数量，如果超过流控阈值就会被限速
# COUNT_CONFLICTS_DETECTED      #未通过冲突检测检查的事务数    
# COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE  #等待被应用的远程事务数量，检查确认过的事务才会进行应用队列，如果超过流控阈值就会被限速
# COUNT_TRANSACTIONS_REMOTE_APPLIED           #已应用的事务数

三、MGR集群日常管理

1、节点退出与恢复

如果有节点发生异常退出后，重启该节点MGR功能，观察状态是否会从RECOVERING转变为ONLINE（RECOVERING阶段会从集群中拉取数据进行恢复，需要一个过程），如果无法成功RECOVERING会被集群剔除

mysql > select * from performance_schema.replication_group_members #节点状态检查
mysql > start group_replication   #节点重启后需要执行该命令

2、节点切换

· 自动切换

关闭当前Primary节点或者当节点状态被多数节点判断为异常后自动进行切换

· 手动切换主节点

mysql > select * from performance_schema.replication_group_members   #查看节点member_id
mysql > select group_replication_set_as_primary('xxxxxxx-xxxxxx-xxxxxx');  #指定member_id作为主库

3、单主模式切换为多主模式

SELECT * FROM  performance_schema.replication_group_members;  #单主模式下只有一个MEMBER_ROLE为PRIMARY，其余为SECONDARY
SELECT group_replication_switch_to_multi_primary_mode();  #切换为多主模式
SELECT * FROM  performance_schema.replication_group_members;  #多主模式下全部节点都为PRIMARY

4、多主模式切换为单主模式

SELECT * FROM  performance_schema.replication_group_members; 
SELECT group_replication_switch_to_single_primary_mode();  #切换为单主模式
SELECT * FROM  performance_schema.replication_group_members;