首页

科技
手机搜狐
SOHU.COM

Group Replication的原理

老叶茶馆
2017-05-18
+关注

作者:宋利兵

来源:MySQL代码研究(mysqlcode)

以下是我在DTCC大会上的分享的《深入理解MySQL Group Replication》的核心内容Group Replication架构原理的PPT,分享给大家。

上图是状态机复制的简单原理,其实MySQL的异步复制也是状态机复制。

展开剩余89%

Group Replication使用了原子广播系统的原理:

每个节点上有一个广播模块。

每个广播模块都能接收用户的请求。

广播模块之间进行通讯,对请求进行全局排序。最终每个节点的广播模块上都会有一个顺序完全一样的请求队列。

广播模块将队列中的请求按照顺序发送给DB执行,符合状态机复制的要求(按照同样的顺序执行同样的操作)。因此所有DB的数据保持一致。

原子广播系统我在《由浅入深理解Paxos协议(1)》中有详细的介绍。

Group Replication在实现上有一些变化,但原理是一样的。Group Replication广播的不是原始事务语句而是事务的Binlog Events。因此广播模块是嵌在事务执行流程中的,而不需要和客户端交互。当事务语句执行完准备提交时,Group Replication会捕捉到事务的Binlog Events然后进行原子广播。先执行,再全局排序的方法会导致冲突。即当前事务排在另一个修改了同一行数据的事务的后面,但是执行却在前面。因此需要做冲突检测。

本地事务和远程事务的执行流程不一样,因此分别介绍。

事务在每个节点上都需要在Certify模块进行冲突检测,不管是本地事务还是远程事务。冲突检测的过程是在每个模块上单独进行的,不需要在各个节点之间交互。这里其实是应用了状态机复制的原理,所有节点上的事务都是按照同样的顺序做的冲突检测。因此任何一个事务在所有节点上的冲突检测结果都是相同的。

如果事务在一个节点上认证成功了,那么在其他节点上肯定也是成功的。

如果事务在一个节点上认证失败了,那么在其他节点上肯定也是失败的。

冲突检测有两个因素:

事务是否修改了同样的数据(以行为单位,通过主键识别)。

是否是同时修改的。通过事务执行时的数据库快照版本来判定。数据库的快照是用GTID SET来标识的。事务提交前从全局变量gtid_executed中获取GTID SET。这个GTID SET就是代表了当前事务在提交前,数据库中已经执行了的GTIDs。也即是当前事务提交前,数据库的快照版本。数据库的快照版本会随着事务的Binlog Events一起广播到其他的节点上,用来做冲突检测。

由于时间原因,以下部分未能在DTCC上分享给大家。这里一并分享给大家。

冲突检测数据库中记录了已经通过认证的事务所修改的主键和一个GTID SET。

冲突检测时,从冲突检测数据库中找到当前事务修改的数据的记录。如果没有找到,就没有冲突。如果找到了,则将自己的快照版本和冲突检测数据库中记录的GTID SET进行比对:

如果自己的快照版本中包含了冲突检测数据库中记录的所有GTIDs,那么就没有冲突。自己的快照中包含了,说明该事务在初始节点上执行时,上一次对本行数据的修改已经在初始节点上提交了。所以就不是同时执行的。

如果自己的快照版本中没有包含冲突检测数据库中记录的所有GTIDs,则说明当前事务在初始节点上执行时,上一次对本行数据的修改还没有在初始节点上执行。因此判定为同时执行。

认证成功后,要更新冲突检测数据库。更新后的GTID SET是当前事务的快照版本+当前事务的GTID。

认证失败,不需要更新冲突检测数据库。

推荐订阅原文作者 宋利兵 的公众号 MySQL代码研究

帅哥为什么要拒绝美女的微信?

声明:本文由入驻搜狐号作者撰写,除搜狐官方账号外,观点仅代表作者本人,不代表搜狐立场。

网站地图

用户反馈 合作
Copyright © 2018 Sohu.com