MGR基本要求：

1、InnoDB存储引擎

2、主键，每个表必须具有已定义的主键或等效的主键，其中等效项是非null唯一键

3、IPv4网络

4、网络性能

5、开启二进制日志并开启GTID模式

6、mysql版本在5.7.17以上

MGR限制：

1、组复制不支持mysiam引擎

2、不支持binlog的checksum校验

3、并发DDL与DML操作。使用多主模式时，不支持针对同一对象但在不同服务器上执行的并发数据定义语句和数据操作语句，因为锁不共享

4、具有级联约束的外键

5、非常大的事务

扫描二维码关注公众号，回复： 4041831 查看本文章

6、最多包含9个服务器

组复制协议：

从上图可以看出，在事物执行阶段，分发给各个主机，依据少数服从多数的原则提交事物。

开启replication配置：

所有的实例中必须包含以下参数配置：

server-id=1 #标识服务器唯一

log-bin=mysql-bin #二进制日志开启

enforce_gtid_consistency = ON #GTID模式

binlog-format=row #必须是ROW模式

gtid-mode=ON #GTID保证事物编号全局唯一（Global Transaction ID）

master-info-repository=TABLE

relay-log-info-repository=TABLE #记录同步的信息,便于管理和恢复

log-slave-update = ON #需要记录事务的binlog,用作以后的恢复用,哪怕不是写入点,也需要

binlog-checksum=NONE #MGR本身不支持binlog的checksum校验

slave-parallel-workers=8 #GTID的SQL线程

slave-preserve-commit-order=1　　　　#GTID配置，SQL线程按照顺序重放事物

slave-parallel-type=LOGICAL_CLOCK. 　　#SQL线程工作模式。有两种。

#组复制配置：

　　transaction_write_set_extraction=XXHASH64　　　　#指示服务器对于每个事务，它必须收集写集并使用XXHASH64散列算法将其编码为散列

　　loose-group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"　　　　#命名格式，每个实例必须完全相同

　　loose-roup_replication_start_on_boot=off　　　　　　　　#插件在服务器启动时不自动启动操作

　loose-group_replication_local_address =“127.0.0.1：24903” 　　　　#指定本机地址及端口，是通信端口，不是实例端口

　loose-group_replication_group_seeds= "127.0.0.1:24903,127.0.0.1:24903,127.0.0.1:24903"　　　　#设置组成员的主机名和端口，端口使用的是通信端口，不是实例端口

　loose-group_replication_bootstrap_group=off　　　　　　　　#引导是否开启，选择关闭，手动引导

loose-group_replication_auto_increment_increment=7　　　　　　#指定自增量，默认为7

 loose-group_replication_single_primary_mode = off  　　#关闭单主模式的参数
 loose-group_replication_enforce_update_everywhere_checks = on #开启强制检查

创建复制账号：

SET SQL_LOG_BIN=0;         #不写入二进制日志，避免扩散到其他机器 grant replication slave on *.* to 'backup'@'%' identified by '123456';    #创建复制账号

FLUSH PRIVILEGES;
SET SQL_LOG_BIN=1;

主执行：

CHANGE MASTER TO MASTER_USER='stemp', MASTER_PASSWORD='123456' FOR CHANNEL 'group_replication_recovery';　　　　　　                      #加入组

INSTALL PLUGIN group_replication SONAME 'group_replication.so';　　　　　　#安装组复制插件。mysql自带有这个插件

SHOW PLUGINS;         #查看插件是否安装成功

SET GLOBAL group_replication_bootstrap_group = ON;      #开始引导组
START GROUP_REPLICATION; 　　　　　　　　　　　　　　　　#开启组复制
SET GLOBAL group_replication_bootstrap_group = OFF;　　#关闭引导
查看：

SELECT * FROM performance_schema.replication_group_members;　　　　　　#查看是否加入成功

其他机器执行（加入组复制）：

SET SQL_LOG_BIN=0;            #不写入二进制日志，避免扩散到其他机器 grant replication slave on *.* to 'backup'@'%' identified by '123456';

FLUSH PRIVILEGES;
SET SQL_LOG_BIN=1;

CHANGE MASTER TO MASTER_USER='stemp', MASTER_PASSWORD='123456' FOR CHANNEL 'group_replication_recovery';

INSTALL PLUGIN group_replication SONAME'group_replication.so';

START GROUP_REPLICATION;
这里和第一台机器不同的是不执行引导组的语句。

查看：SELECT * FROM performance_schema.replication_group_members;

MGR使用paxos算法来解决一致性的问题，自己的理解：
比如一场法庭审判：
底下的人都是提议者，可以提出自己的意见和建议，但是，最后做出决定的是法官，这个法官可以是一个或者多个。
提出提议的众人争先和法官联系。每一个提议者都会提出一个意见，这个意见会生成一个唯一的ID。如果有一个提议者和大多数法官（半数以上）取得的联系，那么这个提议就会被接受

法官就会记录这个提议生成的唯一ID，和上一个ID进行对比，如果现在的这个ID大于旧ID，那么这个意见就会被接收，然后法官们一起决定这个意见，以少数服从多数的方式决定。

如果这个ID小于或者等于旧ID，那么法官就会拒绝这个提议，拒绝后，提议者会将这个ID号增加，然后继续向法官提出提议，直到被接受。

在同一时间，只有一个提议能被接受。

当事务准备好在源服务器上提交时，该服务器以广播的方式写入值（已更改的行）和对应的写入集（已更新的行的唯一标识符）。然后为该事物建立全局唯一GTID编号。最终，所有服务器都以相同的顺序接收相同的事务集。因此，所有服务器都以相同的顺序应用相同的更改集，因此它们在组内保持一致。

如果存在冲突，那么提交的第二个事物会发生回滚，因为第一个事物是先提交的。

mysql MGR安装