本文主要介绍MySQL组复制相关知识，包括原理及相关的服务。

什么是MySQL组复制

MySQL Group Replication（MGR）是MySQL 5.7.17引入的服务器插件，可用来创建弹性的、高可用的、容错的复制集群，保证数据库服务持续可用。MGR提供节点之间抢协调性的分布式状态复制，节点间可以自动协调。 MGR可以是单主模式（同一时间只有一个节点接受写操作，且主节点有系统自动选择），多主模式（所有的节点都可接受写操作，即使是同时发送的）两种模式。

MGR内置的组员服务会保持组内所有节点之间的视图的一致性及可用性供所有节点使用，节点加入或者退出时，视图会相应更新，当某个节点故障时，故障检测机制会检测到并通知组其视图已经发生变更，这些都是自动完成的。

对于要提交的事务，组内大多数成员需按照全局事务ID的事务顺序达成一致才能提交，提交或者回滚的事务均有每个节点单独完成，但是所有的节点必须做出相同的决定。如果存在网络分区，导致成员无法达成一致，则系统在问题解决前不会继续执行。这是系统内置的自动保护脑裂的机制。

MGR是基于Group Communication System（GCS）协议的，该协议提供了故障检测机制，组员服务以及安全完整的消息传递服务，这些服务确保了数据在组内复制中的一致性，是创建复制系统的关键，而核心的技术是基于Paxos算法的实现，是组通信的引擎。

MySQL复制技术

主从复制

传统MySQL复制提供的是基于一个源数据库即主节点并复制到一个或多个从节点的复制，主节点应用事务并提交，然后将对数据库的更改发送到从节点上去执行（基于语句的复制）或者是应用（基于行的复制）。默认情况下，所有的节点都包含了一个与主库完全相同的数据，属于shared-nothing的方案。

如下是MySQL异步复制原理

异步复制原理

如下是MySQL半同步复制原理

半同步复制原理

其中，在各个实例之间的箭头表示实例之间的数据交换以及实例和客户端应用程序之间的数据交换。异步复制和半同步复制的区别在于，半同步复制需要等待至少一个从库复制并应用了中继日志收到回应（有一个等待时间，超过这个时间没有收到回应则退化为异步复制）之后再提交，提高主从数据一致性。而异步复制无需等待从库确认，最大化性能。

组复制

组复制是可以用来实现容错系统的技术。复制组是一个服务组，其中的每个服务拥有整个数据的副本，每个服务之间通过消息交流。通信层保证院子消息的传递以及顺序。MGR在此基础上构建并实现了多主更新协议。组内的每个服务独立执行事务，但是每个读写事务均是在组同意后提交，也就是有组来决定是否提交每个读写事务，因此提交操作并非原始服务单方面决定的。读事务不需要组内同意就可以立即提交。

当读写事务在原始服务上准备提交时，服务会先自动将修改的行以及相应的主键广播。由于事务是按照原子广播的，所有的服务，要么都收到事务要么都没有收到。如果接受到，那都是以同样的顺序接受到并且为这个事务建立起一个全局的顺序。在不同服务上同时执行的事务可能会发生冲突，如两个服务上同时对同一行数据进行修改。解决冲突的方法是顺序在前的事务先提交，顺序在后的事务在原始服务上回滚并从组内其他服务中删除。

组复制原理

组复制也是一种shared-nothing的方案，其中每个成员都有自己完整的数据副本。

组复制应用场景

弹性复制：服务的数量可以动态添加和减少且尽可能的减少对原服务的影响，如云数据库服务
高可用分片：分片是写扩展的流行解决方案，使用MGR来实现高可用分片，每个分片映射到一个复制组。
主从复制替代方案：某些情况下，使用单主服务可能会使其成为连接热点，使用多主会更具扩展性。

组复制相关服务

组员服务

在MGR中，一组服务组成一个复制组。有组名，组时动态的，服务可以在任何时候加入或者离开，组会自动调整。如果有服务加入组，则会从已有的服务中将丢失的状态同步至最新。如果有服务离开，则其余的服务会重新配置组。组员服务定义了哪些服务是在线的并参与到组的，在线的服务列表通常是一个视图。组内的每个服务都有一个一致性视图，说明哪些服务是此刻参与到组复制的成员。组成员不仅仅要统一提交事务，还要统一当前的视图是哪一个如果已有的成员同意新的服务加入称为组的一部分，则组会重新配置，引发视图变更。如果服务离开（自愿与否），组会动态重新配置并引发视图变更。当组员自动离开时，不需要经过大多数成员的同意即可进行重新配置。如果是被动离开如宕机、断网，组复制故障检测机制检测到之后，需要组内成员协商，大部分成员同意之后才能重新配置。

故障检测服务

组复制包含了故障检测机制，能够发现并报告那个服务是已经不可用了。当服务A在一段时间内无法接收到服务B的消息并引发超时，会怀疑服务B异常，如果组内其他成员也同意此怀疑，则会将服务B认为是异常的并将该服务排除在组外。当一个服务与所有其他组都无法通信时，会怀疑自己异常，但是因为无法通过协商与组达成一致，因此该怀疑不会产生结果。

容错

MGR是建立在Paxos分布式算法的实现上，用来在服务之间进行分布式协商决策，因此需要大多数服务处于活动状态达到法定票数才能做决策。这直接影响了系统中能够出错而不影响整体功能的服务个数，设能够允许出错的服务个数为f，则总服务n=2*f+1. 在实际应用中，允许一个服务故障则需要有3个服务，当一个服务故障时，仍然有两个服务来组成大多数票数并允许系统继续自动决策，但是如果有两个服务故障，则复制组阻塞，一个服务无法组成大多数的票数来做决策。