MySQL分布式事务深入解析

MySQL分布式事务深入解析-MySQL社区 Inside MySQL Group

众所周知,MySQL数据库支持分布式事务。简单来说,事务支持ACID特性,分布式事务需要在每个节点都支持ACID,可视为更高级的事务要求,即多个节点要么都提交,要么都回滚。例如常见不同银行之间的转账,就是一个典型的分布式事务。

MySQL分布式事务采用XA标准,分为两种类型:内部XA事务、外部XA事务。内部XA事务是由于MySQL插件式存储引擎存在的特殊性。一个典型的应用是binlog插件与InnoDB存储引擎的日志数据需要是一致,从而保证主从环境数据的一致性。详情可以参考《MySQL技术内幕:InnoDB存储引擎》7.7节

外部XA事务是通常定义的分布式事务。MySQL数据库本身提供XA事务支持,例如常见的InnoDB存储引擎。因此,用户可以通过JTA实现分布式事务应用。在MySQL XA事务中,应用程序是协调者(coordinator),参数事务的服务器节点就是资源管理器(resource manager)。然而通常在线上环境中,很少有发现MySQL XA事务的使用,个人总结来说,主要存在以下两个问题:

问题1:当参数分布式事务的协调者退出后,即使参与分布式事务的节点都已经PREPARE成功。从理论上说,这时这些分布式事务是悬挂事务,协调者恢复后可以进行最后的第二阶段提交。但是这在MySQL数据库中是不可行的,协调者退出,整个XA事务都回滚。具体的例子可见下面的视频:

问题2:参与分布式事务的节点已经PREPARE成功,但是发生数据库宕机导致重启。这时重启之后可以发现悬挂的XA事务,可以进行提交。但是提交后,不写入二进制日志文件,这时会导致主从数据不一致。具体的例子可见下面的视频:

问题1其实并不会有任何的不良影响,只是与传统的分布式事务实现不同。即PREPARE成功的事务会丢失,但是各资源服务器上的数据还是一致的。

问题2,分布式事务在故障后最终依然可以提交,但是主从的数据会不一致,这对高一致性的环境要求不符。导致这个问题的原因在于参与分布式事务的节点PREPARE成功,但是其没有写二进制日志,虽然这可以从一定程度可以提高分布式事务的性能,但是忽略了数据一致性的考虑。

那就写二进制日志嘛,问题不就解决了?是的,貌似可以。但是这对replication有很大的影响。因为分布式事务的PREPARE是在事务提交前就写了,但是二进制日志实在事务提交时才写的。这样会导致replication由于分布式事务,而导致可能被长时间等待的情况。

就这个问题我们邮件了MariaDB开发组,他们回复了,但是说这些问题已经在官方文档中注明[1],可能觉得优先级不是很高吧。所以,在网易的MySQL分支版本InnoSQL中,已经对该问题进行了修复。修复的方案很简单,PREPARE成功的事务写日志,但并不是写在二进制日志中,而是写在每个对应分布式事务的单独文件中。

最后,祝大家玩的开心。

参考文献:

[1]. http://dev.mysql.com/doc/refman/5.6/en/xa-restrictions.html
[2]. http://www.percona.com/live/mysql-conference-2013/sites/default/files/slides/XA_final.pdf

发表评论

坐等沙发
相关文章
MySQL 8.0 200W QPS!!!InnoDB大重构 #M1005#
MySQL 8.0 200W QPS!!!InnoDB大重构 …
滚蛋吧,MySQL主从复制延迟
滚蛋吧,MySQL主从复制延迟
MySQL 8.0.3性能大杀器 —— CATS
MySQL 8.0.3性能大杀器 —— CATS
2017年MySQL数据库技术嘉年华 —— 有态度的技术大会
2017年MySQL数据库技术嘉年华 —— 有态度…
IMG社区MySQL技术沙龙南京站圆满结束
IMG社区MySQL技术沙龙南京站圆满结束
改朝换代:MySQL Group Replication
改朝换代:MySQL Group Replication
myadmin 订阅者
我还没有学会写个人说明!

一触即发,2017年,数据库世界的诸神之战