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

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

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

图 1：主从复制示意图

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

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

图 4：半同步示意图

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

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

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

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

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

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

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

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

图 6：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 模块，各个节点各自进行冲突检测验证，最终保证事务在集群中最终一致性。

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

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

介绍冲突检测实现原理之前，先介绍一下广播信息 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 事务快照版本。

图 9：certification info 结构图

图 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<UUID_MGR:1-101，则 T3 冲突检测失败，事务回滚或者丢弃。

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

如下图所示，三个事务 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：多事务同时写入结果图

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

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

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

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

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

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

图 13：MGR 技术闪亮点

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

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