悄悄告诉你 MySQL MGR 牛在哪?

大家听过 MySQL MGR 技术吗？

MySQL 是目前最流行的开源关系型数据库，国内金融行业也开始全面使用，其中MySQL 5.7.17 提出的 MGR（MySQL Group Replication）既可以很好的保证数据一致性又可以自动切换，具备故障检测功能、支持多节点写入，MGR 是一项被普遍看好的技术。本文给大家介绍一下 MySQL MGR 技术演变过程、事务生命周期及事务冲突检测机制。

先介绍 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所示，三个人对话，一个人在不停歇的演讲，不需要知道两个听众是否听懂，听众也不需要做出回应，等演讲完毕，有可能听众没听懂，最终大家认知到信息可能不一致，为了解决上述问题MySQL5.5.8 就有了半同步复制。

图3 异步复制场景模拟图

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

图4 半同步示意图

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

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

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

MySQL 5.7 版本的MGR技术可以解决上述问题。

图5 半同步复制场景模拟

至此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 层内部处理过程。

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集群中从开始到结束整个处理过程，接下从局部角度详细介绍冲突检测机制实现机制。

transaction message和certification info分别是什么？

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

1 transaction message

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

具体组成：

1. write set 叫写入集合，是事务更新行相关信息的Hash值。

   write set=Hash（库名+表名+主键（唯一键）字段信息）

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

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

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

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

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

图8 广播信息的内容结构

2 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 结构图

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

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

反之，事务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协议模块达成一致性共识，进行冲突检测时遵循下面三个原则：

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

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

3. 不同的事务对同一个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信息。

MGR技术特点有哪些？

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

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

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

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

4. 有单主和多主模式。

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

图13 MGR技术闪亮点

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

总结展望

MySQL是应用最广泛的一个开源数据库 ，其中MGR技术在保证数据一致性基础上，可自动进行故障检测、自动切换，具备防脑裂机制，兼具多节点写入等优点，是一个很好的技术发展方向。目前部分银行应用MySQL比例较高，并且也已开始推广上线MGR架构；G行数据库数据库规划秉持传统数据库和开源数据库并行使用模式，MySQL线上应用也有上百套，其中的A类系统中的分布式企业总线开始应用实践MGR技术。后续还将持续推广该项技术，不断提升开源数据库技术管理水平。

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

来源：本文转自公众号匠心独运维妙维效，点击查看原文。

送您福利

GNSEC 2020 全球新一代软件工程线上峰会！

  2020.6.19  

门票限时 免费 抢！

长按识别二维码 ▲

近期好文：

一文搞懂什么是 vlan、三层交换机、网关、DNS、子网掩码、MAC地址

运维必看：日志标准化必须面对的 4 类问题

云管理神器：利用 Terraform 实现云上基础设施即代码

运维遇上中台，送分或送命？我是这样理解的

投稿邮箱：[email protected]，或添加联系人微信：greatops1118

点个“在看”，一年不宕机