MGR--组复制

MySQLDBA修炼之路 2019-08-12

493

5.7 的复制，表级别的复制，没有实现writeset级别复制

5.7 mgr实现了writeset复制（表里面一定有主键或者非空唯一索引）

MGR介绍

MySQL Group Replication（下简称：MGR）是MySQL官方推出的一种基于Paxos协议的状态机复制。在MGR出现之前，用户常见的MySQL高可用方式，无论怎么变化架构，本质就是Master-Slave架构。MySQL 5.7版本开始支持无损半同步复制（lossless semi-sync replication），从而进一步提示数据复制的强一致性

1.1 MySQL异步复制

master事务的提交不需要经过slave的确认，slave是否接收到master的binlog，master并不care。slave接收到master binlog后先写relay log，最后异步地去执行relay log中的sql应用到自身。由于master的提交不需要确保slave relay log是否被正确接受，当slave接受master binlog失败或者relay log应用失败，master无法感知

1.2 MySQL半同步复制

基于传统异步存在的缺陷，mysql在5.5版本推出半同步复制。可以说半同步复制是传统异步复制的改进，在master事务的commit之前，必须确保一个slave收到relay log并且响应给master以后，才能进行事务的commit。但是slave对于relay log的应用仍然是异步进行的，原理如下图所示:

1.3 MySQL组复制（MGR）

基于传统异步复制和半同步复制的缺陷——数据的一致性问题无法保证，MySQL官方在5.7.17版本正式推出组复制（MySQL Group Replication，简称MGR）。由若干个节点共同组成一个复制组，一个事务的提交，必须经过组内大多数节点（N 2 + 1）决议并通过，才能得以提交。如上图所示，由3个节点组成一个复制组，Consensus层为一致性协议层，在事务提交过程中，发生组间通讯，由2个节点决议(certify)通过这个事务，事务才能够最终得以提交并响应。引入组复制，主要是为了解决传统异步复制和半同步复制可能产生数据不一致的问题。组复制依靠分布式一致性协议(Paxos协议的变体)，实现了分布式下数据的最终一致性，提供了真正的数据高可用方案(是否真正高可用还有待商榷)。其提供的多写方案，给我们实现多活方案带来了希望。

当客户端发起commit命令时（此时没有发生真正的commit），所有本事务内对数据库的更改行的主键都会被写入到每个节点的队列中。如果认证测试失败，写入集会被丢弃并且原始事务会被回滚；如果认证成功，事务会被提交并且写入集会被在剩余节点进行应用。最终，这意味着所有服务器以相同的顺序接收同一组事务。

引入组复制，主要是为了解决传统异步复制和半同步复制可能产生数据不一致的问题。组复制依靠分布式一致性协议(Paxos协议的变体)，实现了分布式下数据的最终一致性，提供了真正的数据高可用方案。

MySQL组复制的特性和限制

特性优点：

1、高一致性，基于原生复制及paxos协议的组复制技术，并以插件的方式提供，提供一致数据安全保证；2、高容错性，只要不是大多数节点坏掉就可以继续工作，有自动检测机制，当不同节点产生资源争用冲突时，不会出现错误，按照先到者优先原则进行处理，并且内置了自动化脑裂防护机制；3、高扩展性，节点的新增和移除都是自动的，新节点加入后，会自动从其他节点上同步状态，直到新节点和其他节点保持一致，如果某节点被移除了，其他节点自动更新组信息，自动维护新的组信息；4、高灵活性，有单主模式和多主模式，单主模式下，会自动选主，所有更新操作都在主上进行；多主模式下，所有server都可以同时处理更新操作。

MGR搭建

192.168.168.101 master 通讯端口34901

192.168.168.102 slave1 通讯端口34902

192.168.168.103 slave2 通讯端口34903

loose-group_replication_member_weight=50

权重：新主选举时的优先级参照，越大，优先级越高

多主节点搭建基本和单主步骤一样，只需要配置文件my.cnf额外添加，本文以下示例为单主节点搭建，多主节点搭建亦相差无几

loose-group_replication_single_primary_mode=FALSE

loose-group_replication_enforce_update_everywhere_c

hecks= TRUE

1、在三台主机上配置设置主机名及IP映射

2、关闭防火墙

查看centos7的防火墙firewall-cmd --state停止firewallsystemctl stop firewalld.service禁止firewall开机启动systemctl disable firewalld.service

3、配置文件

#repslave-parallel-type=LOGICAL_CLOCKslave-parallel-workers=16master_info_repository=TABLErelay_log_info_repository=TABLErelay_log_recovery=ONbinlog_checksum=NONEslave_preserve_commit_order=1#group_replication_flow_control_mode=DISABLED

gtid_mode=onlog_slave_updates=1enforce_gtid_consistency=1

#MGRtransaction_write_set_extraction =XXHASH64loose-group_replication_group_name ="a876d35e-9110-11e6-a365-842b2b5909d6"loose-group_replication_start_on_boot =offloose-group_replication_local_address ="192.168.168.101:34901"loose-group_replication_group_seeds ="192.168.168.101:34901,192.168.168.102:34902,192.168.168.103:34903"loose-group_replication_bootstrap_group =offloose-group_replication_single_primary_mode = trueloose-group_replication_enforce_update_everywhere_checks = false

不能放在[mysql]下

salve2

slave3

4、安装插件INSTALL PLUGIN group_replication SONAME 'group_replication.so';show plugins;

5、配置恢复渠道

M1 S1 S2都操作

SET SQL_LOG_BIN=0;CREATE USER rep@'%';GRANT REPLICATION SLAVE ON *.* TO rep@'%' IDENTIFIED BY 'rep';FLUSH PRIVILEGES;SET SQL_LOG_BIN=1;CHANGE MASTER TO MASTER_USER='rep', MASTER_PASSWORD='rep' FOR CHANNEL 'group_replication_recovery';

M1启动SET GLOBAL group_replication_bootstrap_group=ON;

START GROUP_REPLICATION;

S1 S2直接启动START GROUP_REPLICATION;

6、查看mgr的状态

# 查询表performance_schema.replication_group_members

select * from performance_schema.replication_group_members;

STOP GROUP_REPLICATION;会根据权重重新选择新的主master

START GROUP_REPLICATION;新加入后作为从服务器slave

查看是否主节点SELECT IF((SELECT @@server_uuid) = (SELECT VARIABLE_VALUE FROM performance_schema.global_status WHERE VARIABLE_NAME= 'group_replication_primary_member'), 1, 0) as is_primary_node;