从一个线上问题分析binlog与内部XA事务提交步骤

2024-09-07 22:13:04

字体：大中小

来源：转载

供稿：网友

从一个线上问题分析binlog与内部XA事务提交步骤：

　　1. 问题
　　业务上新增一条订单记录，用户接收到BinLake拉取的MySQL从库数据消息后，马上根据消息内的订单号去查询同一个MySQL从库，发现有些时候无法查到该条数据，等待大约500ms～1000ms后再去查询数据库，可以查询到该条数据。
　　注: BinLake为京东商城数据库技术部自研的一套订阅和消费MySQL数据库binlog的组件，本例所描述的问题是业务方希望根据订阅的binlog来获取实时订单等业务消息。
　　2. Binlog与内部XA
　　2.1. XA的概念
　　XA(分布式事务)规范主要定义了(全局)事务管理器(TM: Transaction Manager)和(局部)资源管理器(RM: Resource Manager)之间的接口。XA为了实现分布式事务，将事务的提交分成了两个阶段：也就是2PC (tow phase commit)，XA协议就是通过将事务的提交分为两个阶段来实现分布式事务。
　　两阶段
　　1）prepare 阶段
　　事务管理器向所有涉及到的数据库服务器发出prepare"准备提交"请求，数据库收到请求后执行数据修改和日志记录等处理，处理完成后只是把事务的状态改成"可以提交",然后把结果返回给事务管理器。即：为prepare阶段，TM向RM发出prepare指令，RM进行操作，然后返回成功与否的信息给TM。
　　2）commit 阶段
　　事务管理器收到回应后进入第二阶段，如果在第一阶段内有任何一个数据库的操作发生了错误，或者事务管理器收不到某个数据库的回应，则认为事务失败，回撤所有数据库的事务。数据库服务器收不到第二阶段的确认提交请求，也会把"可以提交"的事务回撤。如果第一阶段中所有数据库都提交成功，那么事务管理器向数据库服务器发出"确认提交"请求，数据库服务器把事务的"可以提交"状态改为"提交完成"状态，然后返回应答。即：为事务提交或者回滚阶段，如果TM收到所有RM的成功消息，则TM向RM发出提交指令；不然则发出回滚指令。

　　2.2. redo与binlog的一致性问题
　　我们MySQL为了兼容其它非事务引擎的复制，在server层面引入了 binlog, 它可以记录所有引擎中的修改操作，因而可以对所有的引擎使用复制功能；然而这种情况会导致redo log与binlog的一致性问题；MySQL通过内部XA机制解决这种一致性的问题。
　　第一阶段：InnoDB prepare， write/sync redo log；binlog不作任何操作；
　　第二阶段：包含两步，1> write/sync Binlog； 2> InnoDB commit (commit in memory)；
　　当然在5.6之后引入了组提交的概念，可以在IO性能上进行一些提升，但总体的执行顺序不会改变。
　　当第二阶段的第1步执行完成之后，binlog已经写入，MySQL会认为事务已经提交并持久化了(在这一步binlog就已经ready并且可以发送给订阅者了)。在这个时刻，就算数据库发生了崩溃，那么重启MySQL之后依然能正确恢复该事务。在这一步之前包含这一步任何操作的失败都会引起事务的rollback。
　　第二阶段的第2大部分都是内存操作，比如释放锁，释放mvcc相关的read view等等。MySQL认为这一步不会发生任何错误，一旦发生了错误那就是数据库的崩溃，MySQL自身无法处理。这个阶段没有任何导致事务rollback的逻辑。在程序运行层面，只有这一步完成之后，事务导致变更才能通过API或者客户端查询体现出来。

（编辑：武林网）

上一篇：pt-online-schema-change 在线修改表构架

下一篇：返回列表