悄悄告诉你MySQL MGR到底牛在哪？

1

大家听过 MySQL MGR 技术吗？

MySQL 是目前最流行的开源关系型数据库，国内金融行业也开始全面使用，其中 MySQL 5.7.17 提出的 MGR（MySQL Group Replication）既可以很好的保证数据一致性又可以自动切换，具备故障检测功能、支持多节点写入，MGR 是一项被普遍看好的技术。

本文给大家介绍一下 MySQL MGR 技术演变过程、事务生命周期及事务冲突检测机制。

2

MGR 技术演进

传统的 MySQL 主从复制架构是 MySQL 保持数据一致性的最基本架构，如下图 1 所示，一主一从架构，从库给主库发起读数据请求后，主库会通过 dump线程把 binlog 日志文件推送给从库，从库的 I/O 线程把接收到数据更新到 relay log，之后从库的 SQL 线程把 relay log 应用为 binlog 日志，直到主库与从库的 binlog 日志文件完全数据一致，达到主从同步。

图 1：主从复制示意图

接下来我们看一下 MySQL 异步复制，如下图 2 所示，一主两从架构，应用发来的事务请求，经过执行之后写入 binlog，主库 master 把 binlog 日志推送给从库 salve1 和 slave2 ，主库不需要等到从库是否成功更新数据到 relay log，主库直接提交事务即可。这种模式牺牲了数据一致性，不能很好保证主从数据一致性。

图 2：异步复制示意图

模拟异步复制场景举例，如下图 3 所示，三个人对话，一个人在不停歇的演讲，不需要知道两个听众是否听懂，听众也不需要做出回应，等演讲完毕，有可能听众没听懂，最终大家认知到信息可能不一致，为了解决上述问题 MySQL 5.5.8 就有了半同步复制。

图 3：异步复制场景模拟图

接下来看一下 MySQL 的半同步复制，如下图 4 所示，一主两从架构，应用发来的事务请求，在主库执行后写入 binlog，主库 master 把 binlog 日志推送给从库 salve1 和 slave2 ，半同步主库需要等待其中任意一个从库更新数据到 relay log 成功并且告知主库，主库才提交事务，这样保证至少有一个从库同步上数据了，也缩短了延迟时间，保证了数据安全。

图 4：半同步示意图

模拟半同步复制场景举例，如下图 5 所示，三个人对话，一个人在不停歇的演讲，任意一个听众回应听懂了，演讲者就继续往下说，否则停止演讲，最后等演讲结束，至少一听众听懂演讲者的意思，保证信息传递一致性。

这种复制模式也存在两个问题：

MySQL 无法自动切换，需要借助外力切库，运维复杂。

从库 Slave 的读压力太大会导致复制延迟不断增加。

MySQL5.7 版本的 MGR 技术可以解决上述问题。

图 5：半同步复制场景模拟

3

至此 MGR 技术诞生！

MGR（MySQL Group Replication）是 MySQL 自带的一个插件，可以灵活部署。

MySQL MGR 集群是多个 MySQL Server 节点共同组成的分布式集群，每个 Server 都有完整的副本，它是基于 ROW 格式的二进制日志文件和 GTID 特性。

如下图 6 所示为 MGR 架构图，主要是 APIs 层、组件层、复制协议模块层和 GCS API+Paxos 引擎层构成。

如图 6 所示，应用发来的事务从 MySQL Server 经过 MGR 的 APIs 接口层分发到组件层，组件层去 capture 事务相关信息，然后经过复制协议层进行事务传输，最后经过 GCS API+Paxos 引擎层保证事务在各个节点数据最终一致性。这是事务进入 MGR 层内部处理过程。

图 6：MGR 架构示意图

4

MGR 集群中事务整个生命周期啥样？

接下来从全局角度看事务整个生命周期，如下图 7 所示，DB1 、DB2 、DB3 构成的 MGR 集群， 集群中每个 DB 都有 MGR 层，MGR 层功能也可简单理解为由 Paxos 模块和冲突检测 Certify 模块实现。

Paxos 模块是基于 Paxos 算法确保所有节点收到相同广播消息，transaction message 就是广播消息的内容结构；冲突检测 Certify 模块进行冲突检测确保数据最终一致性，其中 certification info 是冲突检测中内存结构。

本文详细介绍冲突检测模块实现原理，Paxos 算法实现部分后续对比 Raft 算法详细介绍。

当 DB1 上有事务 T1 要执行时，T1 对 DB1 是来说本地事务，对于 DB2、DB3 来说是远端事务；DB1 上在事务 T1 在被执行后，会把执行事务 T1 信息广播给集群各个节点，包括 DB1 本身，通过 Paxos 模块广播给 MGR 集群各个节点，半数以上的节点同意并且达成共识，之后共识信息进入各个节点的冲突检测 certify 模块，各个节点各自进行冲突检测验证，最终保证事务在集群中最终一致性。

在冲突检测通过之后，本地事务 T1 在 DB1 直接提交即可，否则直接回滚。远端事务 T1 在 DB2 和 DB3 分别先更新到 relay log，然后应用到 binlog，完成数据的同步，否则直接放弃该事务。

图 7：MGR 组复制技术示意图

前面我们从全局视角介绍了一个事务在 MGR 集群中从开始到结束整个处理过程，接下从局部角度详细介绍冲突检测机制实现机制。

5

transaction message 和 certification info

分别是什么？

介绍冲突检测实现原理之前，先介绍一下广播信息 transaction message、冲突检测内存 certification info 的结构组成。

transaction message

如图 8 所示，transaction message 保存是事务 T1 要更新行的的相关信息,有 transaction_context_log_event 和 gtid_log_event 及 log_event_group 三部分组成。

具体组成：

write set 叫写入集合，是事务更新行相关信息的 Hash 值。write set=Hash（库名+表名+主键（唯一键）字段信息）

gtid_executed 为已经执行过的事务 gtid 集合，也即事务快照版本。

把 write set 和 gtid_executed 打包成为事务上下文信息，transaction_context_log_event。

gtid_log_event为已经执行过的事务 gtid 集合。

log_event_group 为事务日志信息，后续要更新到 relay log 中。

把 3 和 4 和 5 一起打包成为 transaction message 广播给其它节点。

图 8：广播信息的内容结构

certification info

广播的信息到达冲突检测模块 certification 之后是如何工作？

每个节点都有一个 certification info 的内存结构，certification info 保存了通过冲突检测的事务的 write set 和 gtid_executed。

certification info 相当于一个 map，key 是 string 结构，保存 write set 中提取的主键值；value 是 set 集合，保存 gtid_executed 事务快照版本。

例如 T1 事务，T1 更新数据库 d1 中的表 t1 中两行数据 id=1 和 id=2，它对应快照版本 UUID_MGR 是 :1-100，刚开始 certification info 为空，所以直接提交，之后 certification info 中快照版本直接更新为 1-101。

图 9：certification info 结构图

6

冲突检测核心机制！敲黑板！

通过上面的例子可知通过冲突检测标准：若 transaction UUID_MGR ">="certification info UUID_MGR，则冲突检测通过。

图 10：冲突检测事务执行举例

根据上述标准举例，事务 T2，更新 id=2 的行，事务 T2 的 UUID_MGR 为 1-102，节点中冲突检测模块中的 certification info 中的 UUID_MGR 为 1-101，这里 T2:UUID_MGR:1-102>UUID_MGR:1-100，则 T2 冲突检测通过。

反之，事务 T3，更新 id=1 的行，事务 T3 的 UUID_MGR 为 1-100, 节点中冲突检测模块中的 certification info 中的 UUID_MGR 为 1-101，很明显 T3:UUID_MGR:1-100

上面是针对于单独一个写来进行判断，现在我们来展示一下多节点模式中，多个事务同时写入时冲突检测机制。

如下图所示，三个事务 T4、T5、T6 并行写入某个 MySQL 节点，通过了 Paxos 协议模块达成一致性共识，进行冲突检测时遵循下面三个原则：

多个事务修改同一个 id 对应的数值，需要按照先后顺序进行冲突检测。

多个事务同时对不同的 id 进行修改，各自进行修改即可。

不同的事务对同一个 id 修改，需要按照先后顺序进行冲突检测即。

图 11：多事务同时写入示意图

如图 11 所示，事务 T4 和事务 T5 同时更新 id=1 的行，按照先来后到顺序进行冲突检测，T4 先到先进行冲突检测。

事务 T4，更新 id=1 的行，事务 T4 的 UUID_MGR 为 1-102，节点中冲突检测模块中的 certification info 中 id=1 的 UUID_MGR 为 1-101，很明显 T2:UUID_MGR:1-102>UUID_MGR:1-101，则 T4 冲突检测通过，更新为 certification info 中 UUID_MGR 为 1-103。

事务 T5，更新 id=1 的行，事务 T5 的 UUID_MGR 为 1-100, 节点中冲突检测模块中的 certification info 中 id=1 的 UUID_MGR 为 1-102，其中 T5:UUID_MGR:1-100>UUID_MGR:1-102，则 T5 冲突检测不通过。

事务 T6，更新 id=3 的行，事务 T6 的 UUID_MGR 为 1-100, 节点中冲突检测模块中的 certification info 中 id=3 的 UUID_MGR 为空，其中 T6:UUID_MGR:1-100>UUID_MGR，则 T6 冲突检测通过,更新为 certification info 中 UUID_MGR 为 1-101。

如下图 12 所示，事务 T4 和事务 T5 并行修改 id=1，T4 写入成功，T5 丢弃，T6 写入 id=3 事务，写入成功。

图 12：多事务同时写入结果图

随着 write set 不断写入 certification info 中，内存消耗会相应增大，MGR 有配套的 write set 清理线程，每隔一段时间去清理已经在节点应用或者回放的事务的 write set 信息。

7

MGR 技术特点有哪些？

如下图 13 所示，MGR 具备以下技术特点：

MGR 是基于 Paxos 协议和原生复制的分布式集群，大多数节点同意即可以通过议题的模式，数据一致性高。

具备高可用、自动故障检测功能，可自动切换。

可弹性扩展，集群自动的新增和移除节点，集群最多接入 9 个节点。

有单主和多主模式。支持多节点写入，具备冲突检测机制，可以适应多种应用场景需求。

图 13：MGR 技术闪亮点

MGR 目前还存在一些功能限制和不足，但是是未来数据库发展的一个趋势，随着产品不断完善，MGR 必将引领数据库系统发展的潮流。

8

总结展望

MySQL 是应用最广泛的一个开源数据库 ，其中 MGR 技术在保证数据一致性基础上，可自动进行故障检测、自动切换，具备防脑裂机制，兼具多节点写入等优点，是一个很好的技术发展方向。

目前部分银行应用 MySQL 比例较高，并且也已开始推广上线 MGR 架构；G 行数据库数据库规划秉持传统数据库和开源数据库并行使用模式，MySQL 线上应用也有上百套，其中的 A 类系统中的分布式企业总线开始应用实践 MGR 技术。后续还将持续推广该项技术，不断提升开源数据库技术管理水平。

最后跟大家梳理一下文章内容，先介绍 MySQL MGR 技术演变过程，然后全局阐述了事务生命周期，最后详细解释了事务冲突检测机制，文章略长但干货够足，大家看懂了没？

今晚八点，大咖来了