Mysql官方高可用集群模式:Mysql Group Replication（MGR组复制）

Mysql数据库是开源数据库领域中的佼佼者，大量广泛被应用于各种互联网企业中，其较高的稳定性、相对简单的使用方法、成熟火热的社区、提供事务等方面，使其称为大部分企业的首选事务型数据库。
然而，以前Mysql一直为人诟病的一点是官方没有提供可扩展的高可用集群模式。所以大部分企业不得不自己进行相关的开发来应对这种情况，例如根据业务进行数据库拆分，使用主从模式来进行读写分离以及提供高可用。后开虽然有galera等集群模式出现，但也不是官方出品，在技术选型上也难免让人难以抉择。

th.jpeg

什么是MGR?

官方显然也是知道Mysql集群模式的迫切，终于在5.7版本以后提供了Mysql的高可用集群模式MGR。MGR是Mysql Group Replication(组复制)的缩写，Mysql5.7之后是以一个Mysql插件的形式集成在Mysql中，用于创建可伸缩、高可用、可容错的复制架构，是Mysql集群的一种形式。MGR包括一套内置的组成员服务，包括节点的自动加入、离开，故障检测等机制。这些机制的协调，保障了Mysql集群能够达到数据的一致性。

MGR出现的背景

从技术层面来说，目前容错系统(集群模式)一般是使用冗余组建的方式，提供多个节点，但这就意味着需要对这些冗余的节点进行管理，就会碰到诸如网络分区、脑裂等问题，Mysql集群也避免不了的会碰到这些问题。

所以困难点在于如何让Mysql集群中的每个节点对于集群中的每一次改动都认同，对于当前整个Mysql集群的状态认同，换句话说最终各个节点能够收敛到相同的状态。
这明显就是一个状态机，最终状态机的状态保持一致是我们的目标。

MGR(组复制)正是Mysql提供的状态机复制技术。在MGR(组复制)中每个服务器都能看到其他组内节点的状态，在MGR中称之为视图(view)，MGR内置group membership service,为每个节点提供一致的视图，节点的离开、加入都会触发视图的改变，而因为网络异常的原因退出的节点，也会有相应的故障检测机制来发现。

MGR的一个重要特点是对于要提交的事务，组中的大多数必须在全局事务序列中约定给定交易的顺序，决定提交或中止事务是由每个服务器单独完成的，MGR保证所有的服务器都做出相同的决定。

所有这些功能都依赖于底层的节点间通信和协调算法。在Mysql中被称为Group Communication System (GCS)，它提供了故障检测机制、组成员服务以及安全且完全有序的消息传递，其底层基于paxos算法。

复制技术

Mysql Group Replication组复制本身也是Mysql提供的一种复制技术。我们知道Mysql本身已经提供了主从复制的技术，那这两者有什么区别呢？

• 主从复制
  传统Mysql复制技术为主从复制，一般存在一个master服务器，一个或者多个slave服务器，master执行事务并且提交，稍后binlog被复制到slave，在slave中基于状态、基于行进行复制。它是一个无共享的系统，所有服务器在默认情况下都有完整的数据副本。

  • 异步复制
    

    async-replication-diagram.png

  • 半同步复制
    

    semisync-replication-diagram.png

    半同步复制是在master提交之前需要等待binlog传到slave之后，slave恢复ACK给到master,用以确认master执行的事务已经传到了slave，注意这不保证salve应用了这些事务。

• 组复制
  

  gr-replication-diagram.png

  组复制本质上是一种多主更新到处复制的协议，其依赖于底层的组成员间的通讯协议，底层通讯保证了消息的顺序以及原子性。一个重要的特点是组中的成员都是独立地执行事务，但是事务的提交则需要组的协调批准。（只读事务例外，不需要经过组的批准。）

  如上图所示，事务将会被发送到多个组内成员中，由组内的成员单独执行，如果存在两个不同的事务，在不同的组内成员中并发执行，更新相同的行，这就可能会造成冲突，此时因为不是在单节点上，所以还无法使用单节点的加锁机制在解决此问题。组复制中使用certify过程来解决此问题，在执行事务之前，会检查两个不同并发事务的写集来检测此类冲突。(理所当然的，这会牺牲一定的性能)

  组复制同样是一个无共享的复制方案，其中每个服务器都有自己的全部数据副本。

  组复制使得Mysql能够实现容错，并且实现了多写的功能。在部分节点崩溃等情况下，能够实现自动检测和恢复，保证数据库本身还是连续可用的。另外，MGR只是保证数据库的可用性，还需要负载均衡或者路由器等配合，因为可能会出现IP转移等问题，而这部分功能显然是使用独立中间件更合适。

MGR底层机制

• 故障检测机制
  MGR底层实现了分布式故障检测服务，能够自动检测哪些服务器可能存在问题，并经过组内其他成员同意之后将这些服务器排除出组。相对的，对于一个服务器来说，当它从组中分离出来之后，它会怀疑组内所有的其他成员都失败了，由于此时无法实现“过半数”的同意，所以这个服务器的这种怀疑没有结果，它也无法单独对外提供服务。

• 一致性组内视图
  视图是组复制中组内成员都同时维护着的对于组内其他成员的状态表。由于MGR决策过程中需要组内成员的协调，故保持对于组内成员的一致性视图是必要的。引起视图变更的情况有两种:

  • 新成员的主动加入或者旧成员主动离开，都会触发一次成员的变更，并通知到其他成员，等待其他成员大多数同意达成一致。
  • 组内成员的非自动或者意外断开，故障检测机制将会主动发现，并触发一个成员变更，同样的需要等到成员大多数同意才能更新视图，如果无法达成一致，例如剩下的成员无法实现过半数同意的情况，那么就无法形成一致，这会造成脑裂问题。

• 容错性
  MGR底层基于paxos分布式算法，组内节点数n，则允许出错的节点数f=(n-1)/2。只要满足这个条件则可以提供良好的容错性。
  Mysql Group Replication的发布弥补了Mysql在高可用集群方面的缺失，是一大进步。不过Mysql Group Replication组复制也带来了监控和维护相对麻烦的问题，下次再整理一下MGR集群监控和维护相关的知识点，欢迎指正讨论。