MGR

简介

相信很多人对MGR这个词比较陌生，其实MGR(全称 MySQL Group Replication 【MySQL 组复制】)是Oracle MySQL于2016年12月发布MySQL 5.7.17推出的一个全新高可用和高扩展的解决方案。具备以下特性：

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

单主模式(图1)

多主模式(图2)

MGR架构图如下所示：主要包括APIs层，组件层，负责协议模块和API+Paxos引擎层构成。

MGR演进

主从复制

传统mysql复制默认提供了一种简单的主从复制方法,这种架构有一个主,以及一个或多个从,当主节点执行提交事务,然后异步的方式发送到其他的节点,从库重新replay log日志内容达到主副本一致的目的 在默认情况下集群所有节点数据是一致的

半同步复制

异步复制存在一定的数据丢失风险，MySQL又在5.6版本中推出半同步复制，在同步数据协议中添加了一个同步操作，这样意味主节点在commit操作，需要确认最少一个从节点确认接收到并且返回ACK，只有这样主节点才能正确提交数据。

组复制

MySQL MGR 集群最少3个server节点共同组成的分布式集群，一种share-nothing复制方案，每个server节点都有完整的副本。

MySQL组复制协议

MGR技术特性

故障检测

组复制自带提供一种故障检测机制，这个机制能报告哪个组成员是无响应的，并且如何判断该成员是否排除集群组。在组复制中故障检测是一种分布式服务。假设服务器A在预定时间段内未收到来自服务器B的消息，如果组内其他成员也同样未收到来自服务器B的消息，那么确认判断B发生故障，这样由其他成员判定将失联组成员从集群中剔除。

此时服务器B与其他服务节点都无法联系。由于无法达成最小仲裁成员数，处于独立状态，无法对外提供服务。

容错

MySQL组复制构建在Paxos分布式算法基础上实现的，以提供不同server之间的分布式协调。因此，它需要大多数server处于活动状态以达到仲裁成员数，从而做出决定。这对系统可以容忍的不影响其自身及其整体功能的故障数量有直接影响。容忍f个故障所需的server数量(n)n = 2 * f + 1。

实践中，这意味着为了容忍一个故障，组必须有三个server。如果一个服务器故障， 仍然有两个服务器形成大多数(三分之二)来允许系统自动地继续运行。但是，如果第二个server意外地宕掉，则该组锁定(只有一个server)，因为没有达到多数可以达成选举(不能自己选举自己).

成员管理

组复制以组视图(Group View，后续简称视图)为基础来进行成员管理，视图一般在Group在一段时间内的成员状态，如果这段时间没有成员变化，也就是说没有成员的加入和退出，一旦有成员加入或者退出组，则视图就发生变化，并且使用视图ID(view id)进行跟踪变化区分先后时间，下面我们来看一张图演示一下：

PXC和MGR的区别

（1）执行提交PXC 事务需要在所有节点跑一下
MGR 多数节点同意，即可执行
（2）复制
PXC 在复制上需要Gcache中缓存
MGR 直接写binlog
（3）新增节点
新增节点PXC支持mysqldump xtrabackup
MGR直接集成复制克隆
（4）网络中断
网络中断发生时，PXC具有分区的表不可读写
MGR 可读不可写

（5）流控
MGR 写入变慢
PXC所有节点不可写
（6）跨平台
跨平台；PXC支持Linux

MGR支持所有平台（7）DDL当PXC在进行DDL时，为了保证节点数据一致，此时整个集群拒绝写操作，注意是集群内所有的表写操作均无法提供写服务，但是读操作可以正常进行。MGR 采用innodb存储引擎，支持在线DDL