说MGR - MGR中事务的执行过程Part1

MGR中group_replication插件最重要的功能就是事务分发器的功能,这里其分发的是Binlog Event,事务分发器的处理是在事务执行即将结束的时候。MGR将这称作乐观的事务执行策略,可以带来更好的性能。但这种策略下,多个成员上的事务可能发生冲突。MGR需要一个冲突检测机制来发现并处理冲突。根据事务处理过程中的不同处理步骤,MGR中事务分发器的功能划分为以下四个部分。


·本地事务控制模块

·成员间的通信模块

·全局事务认证模块

·异地事务执行模块



先来看下本地事务控制模块,MySQL通过API向插件提供了事务执行过程中几个重要阶段的Hook接口,MGR通过这些接口来监控和控制事务的执行。MySQL的事务在提交时,内部会分成三个阶段:准备(prepare)阶段,记录binlog文件阶段和提交(commit)阶段。MGR对本地事务的控制逻辑在before_commit这个接口中执行。before_commit是在事务的prepare阶段之后,写binlog文件阶段之前被执行的。对本地事务的控制包括以下三个步骤。


1.发送事务信息

MGR首先将事务执行相关的信息打包,通过通信模块的接口发送给本地的通信模块,只要本地的通信模块接收到了消息就返回成功(发送到其它成员是成员间通信模块的职责)。事务信息包括主键信息、数据库快照版本和事务产生的Binlog Event。


·主键信息是Server层生成Binlog Event的时候一同生成的。主键信息中记录的并不是主键字段的值,而是字段值加上库名、表名等哈希值。

·数据库快照版本是当前MySQL的全局变量gtid_executed的值。它包含了当前事务提交时所有已经执行了的事务的GTID,代表了当前事务执行时数据库的状态。

·当发送事务信息时,Binlog Event还没写入Binlog文件。因此,Binlog Event是从当前线程的Binlog Cache中获取的,而不依赖Binlog文件。

·Transaction_context_log_event,本地成员的UUID、主键信息和数据库快照版本会被封装进Transaction_context_log_event中,和事务产生的Binlog Event一起发出去。Transaction_context_log_event放在其它Binlog Event的前面。



2.等待全局事务认证模块的认证结果

在事务信息发送成功后,事务会被阻塞,开始等待全局事务认证模块的认证结果。事务认证完成后,全局事务认证模块会唤醒当前事务的线程,让事务继续执行。



3.认证结果的处理

事务继续执行后,会检测认证结果。如果认证成功了,就继续提交事务。如果认证失败了,就会返回错误。然后由MySQL来执行Rollback的逻辑。


上一篇:开发者社区精选直播合集(三十六)| Flink实践合集


下一篇:MySQL 5.7 MGR单主确定主节点方法