暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

MySQL-XA事务(三)改进与缺陷

MySQLLabs 2019-08-15
2810



B L A C K


1

01-XA-引入xa_prepare_log_event


MySQL-5.7.7版本之后,通过引入xa_preapre_log_event,将完整的事务binlog日志一分为二,分别落盘,用来解决之前版本在客户端退出,或者服务器宕机的情况下,处于xa_prepared状态的事务丢失的情况。如下:

按照官方的说法就是很稳,可以放心使用。


1

02-XA-Prepare持久化? 



官方文笔:

MySQL-5.7.7版本及之后解决了xa_prepared状态的事务丢失的情况,出自官方用户手册,截图如下:

但是实际上,截止到MySQL-5.7.18版本,XA prepare命令返回后,处于xa_prepared状态的事务依然没有被持久化存储,也就是说,如果MySQL宕机,有可能导致数据的丢失,如下图所示。


Innodb跳过prepare阶段的事务日志持久化,其初衷也是为了binlog和redo可以同时进行组提交,但是给XA事务处理过程埋下了隐患。但是话又说回来,在半同步复制场景下,按照这个逻辑,即便master宕机了,只要slave还在,那么返回给客户端(或者是TM)XA prepare成功的事务,在slave实例中都是存在的。




1

03-XA-after_sync? 


如果仔细阅读了MySQL-XA事务(二)源码实现,会发现在XA commit时的一个问题,如下图:

在提交一个处于recovery状态的XA事务时,无论半同步模式是after_sync还是after_commit, InnoDB中的事务提交操作,都被提前到了master实例接收ack之前,对比普通事务,XA事务开启after_sync模式已经失去了一半的意义,但在复制场景中,通过半同步复制来保证数据的最终一致性,还是非常可取的。


XA事务系列文章

MySQL-XA事务(一)简介

MySQL-XA事务(二)源码实现


本文分享自微信公众号 - MySQLLabs,如有侵权,请联系 service001@enmotech.com 删除。
最后修改时间:2019-12-20 11:49:12
文章转载自MySQLLabs,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论