MySQL通过内部XA事务,保持了binlog与redo log之间数据一致性

MySQL通过内部XA事务,保持了binlog与redo log之间数据一致性：

参考：http://www.linuxidc.com/Linux/2015-11/124942.htm

XA 将事务的提交分为两个阶段，而这种实现，解决了 binlog 和 redo log的一致性问题，这就是MySQL内部XA的第三种功能。

MySQL为了兼容其它非事物引擎的复制，在server层面引入了 binlog, 它可以记录所有引擎中的修改操作，因而可以对所有的引擎使用复制功能；MySQL在4.x 的时候放弃redo的复制策略而引入binlog的复制(淘宝丁奇)。

但是引入了binlog，会导致一个问题——binlog和redo log的一致性问题：一个事务的提交必须写redo log和binlog，那么二者如何协调一致呢？事务的提交以哪一个log为标准？如何判断事务提交？事务崩溃恢复如何进行？

MySQL通过两阶段提交(内部XA的两阶段提交)很好地解决了这一问题：

第一阶段：InnoDB redo log prepare，持有prepare_commit_mutex，并且write/sync redo log； 将回滚段设置为Prepared状态，binlog不作任何操作；

第二阶段：包含两步，1> write/sync Binlog； 2> InnoDB redo log commit (写入COMMIT标记后释放prepare_commit_mutex)；

以 binlog 的写入与否作为事务提交成功与否的标志，innodb commit标志并不是事务成功与否的标志。

因为此时的事务崩溃恢复过程如下：

1> 崩溃恢复时，扫描最后一个Binlog文件，提取其中的xid； 

2> InnoDB维持了状态为Prepare的事务链表，将这些事务的xid和Binlog中记录的xid做比较，如果在Binlog中存在，则提交，否则回滚事务。

通过这种方式，可以让InnoDB和Binlog中的事务状态保持一致。如果在写入innodb commit标志时崩溃，则恢复时，会重新对commit标志进行写入；

在prepare阶段崩溃，则会回滚，在write/sync binlog阶段崩溃，也会回滚。这种事务提交的实现是MySQL5.6之前的实现。