MySQL Group Replication调研剖析-组复制的工做原理及程序结构

这是我参与8月更文挑战的第7天，活动详情查看：8月更文挑战

咱们前面提到了MySQL复制的三种模式，接下来咱们聊一下组复制的工做原理和程序结构。

组复制的工做原理

MySQL组复制是一个MySQL插件，它创建在现有的MySQL复制基础结构上，利用了二进制日志，基于行的日志记录和全局事务标识符等功能。它集成了当前的MySQL框架，如性能模式、插件和服务基础设施等。

组复制（Group Replication）基于分布式一致性算法(Paxos协议的变体)实现，一个组容许部分节点挂掉，只要保证绝大多数节点仍然存活而且之间的通信是没有问题的，那么这个组对外仍然可以提供服务，它是一种被使用在容错系统中的技术。\

Group Replication（复制组）是由可以相互通讯的多个服务器（节点）组成的。 在通讯层，Group replication实现了一系列的机制：好比原子消息（atomic message delivery）和全序化消息（total ordering of messages）。这些原子化，抽象化的机制，为实现更先进的数据库复制方案提供了强有力的支持。
MySQL Group Replication正是基于这些技术和概念，实现了一种多主全更新的复制协议。
简而言之，一个Group Replication就是一组节点，每一个节点均可以独立执行事务，而读写事务则会在于group内的其余节点进行协调以后再commit。所以，当一个事务准备提交时，会自动在group内进行原子性的广播，告知其余节点变动了什么内容/执行了什么事务。
这种原子广播的方式，使得这个事务在每个节点上都保持着一样顺序。这意味着每个节点都以一样的顺序，接收到了一样的事务日志，因此每个节点以一样的顺序重演了这些事务日志，最终整个group保持了彻底一致的状态。然而，不一样的节点上执行的事务之间有可能存在资源争用。
这种现象容易出如今两个不一样的并发事务上。假设在不一样的节点上有两个并发事务，更新了同一行数据，那么就会发生资源争用。面对这种状况，Group Replication断定先提交的事务为有效事务，会在整个group里面重放，后提交的事务会直接中断，或者回滚，最后丢弃掉。所以，这也是一个无共享的复制方案，每个节点都保存了完整的数据副本。\

从其工做的原理能够看出，Group Replication基于Paxos协议的一致性算法校验事务执行是否有冲突，而后顺序执行事务，达到最终的数据一致性，也就意味着部分节点能够存在延迟。能够设置多主同时写入和单主写入，经过设置group_replication_single_primary_mode来进行控制是多主仍是单主，官方推荐单主写入，容许延迟，但延迟过大，则会触发限流规则（可配置的），整个集群会变的很慢，性能大打折扣。

组复制的程序结构

在MySQL的底层，GR增长了另外的API层来实现所须要的功能。程序结构上，GRAPI主要分为三部分：

• 1:capture 追踪当前正在执行的事务的上下文。、

• 2:applier 执行远程事务传输到本地的日志到本地数据库。、

• 3:recovery 负责分布式环境下的节点恢复，以及相关的数据回追，失败处理等。

  在这几个主要API层的下面，是统一的复制协议逻辑处理层，这一层主要是统一应用层的各类调用。在更下层，则是通用程度更高的分布式通信层，处于调用便利，分布式通信曾对上提供使用的API，API的下面，是Paxos实现的分布式通信协议组件，这个组件与集群中其余节点一块儿，造成一个虚拟概念化的分布式集群。