Py学习  »  DATABASE

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

酱豆腐文化宫 • 2 年前 • 222 次点击  
阅读 29

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实现的分布式通讯协议组件,这个组件与集群中其他节点一起,形成一个虚拟概念化的分布式集群。

image.png

Python社区是高质量的Python/Django开发社区
本文地址:http://www.python88.com/topic/118444
 
222 次点击