概述

想要建立一个容错的系统，我们需要使所有的组件冗余，换句话来说就是组件可以被移除而不影响系统的功能，因此最大的挑战是让多个服务器协同起来以达到一致的状态，这时可以当成一个数据库或者最终的状态是一致的，而这些在数据库复制中尤为重要

MySQL组复制通过服务器之间的强大协调提供分布式状态机复制。

今天主要讲讲mysql的亲儿子：MGR。

参考：

1、MGR简介

MGR全称MySQL Group Replication（Mysql组复制），是MySQL官方于2016年12月推出的一个全新的高可用与高扩展的解决方案。MGR提供了高可用、高扩展、高可靠的MySQL集群服务。在MGR出现之前，用户常见的MySQL高可用方式，无论怎么变化架构，本质就是Master-Slave架构。MySQL 5.7版本开始支持无损半同步复制（lossless semi-sync replication），从而进一步提示数据复制的强一致性。

　　MGR是MySQL数据库未来发展的一个重要方向。MGR是以Plugin的形式嵌入在MySQL实例中，插件内部实现了冲突检测、Paxos协议通信等。MGR有一个内置的组成员服务，在任何给定的时间点,保持组的视图一致并可供所有服务器使用。服务器可以离开并加入组，视图也会相应更新。当成员离开组，故障检测机制会检测到此情况并通知组视图已更改。

MGR有一个内置的 group membership service 可以在任何时间点提供组一致性和可用性的视图，当成员有加入和移除时会自动的更新。对于一个提交的事务，MGR会按照一定的顺序去同意该操作，无论是同意提交还是回滚所有服务器是独立的进行的，不过需要所有服务器是做出相同的决定以达到一致性。

MGR提供一套内置的自动的，防止脑裂的机制，如果由于某些原因导致无法达成共识，则系统无法继续运行直到问题解决

所有的这些都是由Group Communication System (GCS) 协议提供支持。他提供如下功能

failure detection mechanismgroup membership servicesafe and completely ordered message delivery

所有的这些都是用来保障组内数据复制一致的，内部采用Paxos 算法作为组通讯引擎。

2、MGR特性

MGR具有如下特性：

1）高一致性。基于原生复制及paxos协议的组复制技术，并以插件的方式提供，提供一致数据安全保证；

2）高容错性。只要不是大多数节点坏掉就可以继续工作，有自动检测机制，当不同节点产生资源争用冲突时，不会出现错误，按照先到者优先原则进行处理，并且内置了自动化脑裂防护机制；

3）高扩展性。节点的新增和移除都是自动的，新节点加入后，会自动从其他节点上同步状态，直到新节点和其他节点保持一致，如果某节点被移除了，其他节点自动更新组信息，自动维护新的组信息；

4）高灵活性。有单主模式和多主模式，单主模式下，会自动选主，所有更新操作都在主上进行；多主模式下，所有server都可以同时处理更新操作。

3、MGR的组复制机制细节

3.1、组成员关系(Group Membership)

In MySQL Group Replication, a set of servers forms a replication group. A group has a name, which takes the form of a UUID. The group is dynamic and servers can leave (either voluntarily or involuntarily) and join it at any time. The group adjusts itself whenever servers join or leave.

MGR提供一个组成员关系服务(group membership service )来定义服务器的在线状态以及是否参与组

该关系可以查看视图来获得，该服务保证任何时间查询的视图是一致的

其他成员添加到组和移除出组时会更新该视图，这个过程叫做重配置(reconfiguration)

重新配置过程中需要大多数节点同意，即组内故障服务器低于大多数，否则视图无法更新且会阻塞事务的执行以防止脑裂的发生，这时就需要人为的干预了

3.2、故障检测(Failure Detection)

Group Replication includes a failure detection mechanism that is able to find and report which servers are silent and as such assumed to be dead. At a high level, the failure detector is a distributed service that provides information about which servers may be dead (suspicions). Suspicions are triggered when servers go mute. When server A does not receive messages from server B during a given period, a timeout occurs and a suspicion is raised. Later if the group agrees that the suspicions are probably true, then the group decides that a given server has indeed failed. This means that the remaining members in the group take a coordinated decision to exclude a given member.

MGR包含一个故障检测的机制来发现和报告哪些服务器silent或者dead

故障检测器(failure detector)是一个分布式的服务，用来为哪些服务器故障(怀疑)提供信息

一个服务器被怀疑意味这该服务器无响应(mute)，当服务器A在一段时间内为收到服务器B的信息，一个超时异常发生并且服务器B会被标记为 suspicion状态，这意味着，组内其他的成员服务器会协调将其踢出复制组，如果一个服务器无法和其余的服务器通信，则他会怀疑其他服务器都故障了.由于其服务器和组内其他服务器达成一致，它自身的怀疑是没有结果的，这时他无法执行任何本地事务

3.3、容错机制(Fault-tolerance)

MySQL Group Replication builds on an implementation of the Paxos distributed algorithm to provide distributed coordination between servers. As such, it requires a majority of servers to be active to reach quorum and thus make a decision. This has direct impact on the number of failures the system can tolerate without compromising itself and its overall functionality. The number of servers (n) needed to tolerate f failures is then n = 2 x f + 1.

MGR利用 Paxos分布式算法来协调组内成员，他需要组内到多数服务器在线以达到仲裁成员数从而进行决断 ，例如我们需要容忍f个服务器故障，则组内至少有2 x f + 1个成员。

注意这里的故障指的是异常关闭，服务器正常关闭不属于故障

当超过f个服务器发生故障时，新的节点无法加入组，需要重新引导

4、MGR模式

MySQL Group Replication有两种模式，单主模式single-primary mode和多主模式multi-primary mode，在同一个group内，不允许两种模式同时存在，并且若要切换到不同模式，必须修改配置后重新启动集群

4.1、单主模式

在单主模式下，只有一个节点可以可以读写，其他节点只能提供读，在单主模式下，该参数 group_replication_enforce_update_everywhere_checks 必须被设置为 FALSE ，当主节点宕掉，自动会根据服务器的server_uuid变量和group_replication_member_weight变量值，选择下一个slave谁作为主节点，group_replication_member_weight的值最高的成员被选为新的主节点，在group_replication_member_weight值相同的情况下，group根据数据字典中 server_uuid排序，排序在最前的被选择为主节点

4.2、多主模式

在多主模式下，在加入该群组的所有成员，所有服务器都设置为读写模式，在多主模式下，不支持SERIALIZABLE事务隔离级别，在多主模式下，不能完全支持级联外键约束

篇幅有限，MGR基础理论方面的就介绍到这了，后面在介绍一下MGR搭建方面，感兴趣的朋友可以关注下~