CNDBA社区
1 MGR 概述
在之前的博客我们介绍了MySQL 的两种高可用方案，如下：
MySQL 高可用架构：双主+ haproxy + keepalived
https://www.cndba.cn/dave/article/108024MySQL 高可用架构：双主 + keepalived 搭建手册
https://www.cndba.cn/dave/article/108023
这两种方案都是采用双主的架构，双主架构在一定概率下会有双写的问题。 所以在MySQL中，除了这种双写的架构之外，也会采用mycat、proxysql的方法来解决高可用和读写分离的的问题。
MySQL官方在5.7.17版本推出组复制（MySQL Group Replication，简称MGR）解决方案。
官网说明如下：
https://dev.mysql.com/doc/refman/8.0/en/group-replication.html
MGR架构图如下所示：主要包括APIs层，组件层，负责协议模块和API+Paxos引擎层构成。
主从复制
传统MySQL复制默认提供了一种简单的主从复制方法，这种架构有一个主，以及一个或者多个从，当主节点执行提交事务，然后异步的方式发送到其他从节点，从库重新执行relay log日志内容达到主副本一致的目的，在默认情况下集群所有节点数据都是一致的。
半同步复制
异步复制存在一定的数据丢失风险，MySQL又在5.6版本中推出半同步复制，在同步数据协议中添加了一个同步操作，这样意味主节点在commit操作，需要确认最少一个从节点确认接收到并且返回ACK，只有这样主节点才能正确提交数据。
组复制（MGR）
MySQL MGR 集群最少3个server节点共同组成的分布式集群，一种share-nothing复制方案，每个server节点都有完整的副本。
MGR由若干个节点共同组成一个复制组，一个事务的提交，必须经过组内大多数节点（N / 2 + 1）决议并通过，才能得以提交。组复制的引入，主要是为了解决传统异步复制和半同步复制可能产生数据不一致的问题。组复制依靠分布式一致性协议(Paxos协议的变体)，实现了分布式下数据的最终一致性，提供了真正的数据高可用方案。
2 MGR特点
MySQL Group Replication（MGR）是MySQL官方在5.7.17版本引进的一个数据库高可用与高扩展的解决方案，以插件形式提供，实现了分布式下数据的最终一致性，总结MGR特点如下：
- 高一致性：基于分布式paxos协议实现组复制，保证数据一致性；
- 高容错性：自动检测机制，只要不是大多数节点都宕机就可以继续工作，内置防脑裂保护机制；
- 高扩展性：节点的增加与移除会自动更新组成员信息，新节点加入后，自动从其他节点同步增量数据，直到与其他节点数据一致；
- 高灵活性：提供单主模式和多主模式，单主模式在主库宕机后能够自动选主，所有写入都在主节点进行，多主模式下，所有server都可以同时处理更新操作。
3 组复制故障检测
组复制自带提供一种故障检测机制，这个机制能报告哪个组成员是无响应的，并且如何判断该成员是否排除集群组。在组复制中故障检测是一种分布式服务。假设服务器A在预定时间段内未收到来自服务器B的消息，如果组内其他成员也同样未收到来自服务器B的消息，那么确认判断B发生故障，这样由其他成员判定将失联组成员从集群中剔除。
此时服务器B与其他服务节点都无法联系。由于无法达成最小仲裁成员数，处于独立状态，无法对外提供服务。
4 组复制的限制
- 存储引擎必须为Innodb，即仅支持InnoDB表，并且每张表一定要有一个主键，用于做write set的冲突检测;
- 每个表必须提供主键;
- 只支持ipv4，网络需求较高;
- 必须打开GTID特性，二进制日志格式必须设置为ROW，用于选主与write set;
- COMMIT可能会导致失败，类似于快照事务隔离级别的失败场景;
- 目前一个MGR集群组最多支持9个节点;
- 不支持外键于save point特性，无法做全局间的约束检测与部分部分回滚;
- 二进制日志binlog不支持Replication event checksums;
- 多主模式(也就是多写模式) 不支持SERIALIZABLE事务隔离级别;
- 多主模式不能完全支持级联外键约束;
- 多主模式不支持在不同节点上对同一个数据库对象并发执行DDL(在不同节点上对同一行并发进行RW事务，后发起的事务会失败);
5 容错
MySQL组复制构建在Paxos分布式算法基础上实现的，以提供不同server之间的分布式协调。因此，它需要大多数server处于活动状态以达到仲裁成员数，从而做出决定。这对系统可以容忍的不影响其自身及其整体功能的故障数量有直接影响。容忍f个故障所需的server数量(n)n = 2 * f + 1。
实践中，这意味着为了容忍一个故障，组必须有三个server。如果一个服务器故障， 仍然有两个服务器形成大多数(三分之二)来允许系统自动地继续运行。但是，如果第二个server意外地宕掉，则该组锁定(只有一个server)，因为没有达到多数可以达成选举(不能自己选举自己)。以下是说明上述公式的小表：
6 成员管理
组复制以组视图(Group View，后续简称视图)为基础来进行成员管理，视图一般在Group在一段时间内的成员状态，如果这段时间没有成员变化，也就是说没有成员的加入和退出，一旦有成员加入或者退出组，则视图就发生变化，并且使用视图ID(view id)进行跟踪变化区分先后时间，下面我们来看一张图演示一下：
序号部分，初始化时，第一个视图的序号从1开始，成员只有引导主一个，为进行初始化节点，以后出现的任何成员的加入和退出这个序号都需要增加1，可以通过performance_schema系统库下的replication_group_member_stats表中查询当前视图。
