发现自己的知识点有点散，今天就把它们连接起来，好好总结一下。

一、undo log、redo log、binlog的定义和对比

 二、undo log与redo log的总结和补充

Undo 记录某数据被修改前的值，可以用来在事务失败时进行rollback；重要的是，undo log会产生redo log，也就是undo log的产生也会伴随redo log的产生，这是因为undo log也需要持久性的保护。即undo也是数据页的一部分。

Redo 记录某数据块被修改后的值，可以用来恢复未写入data file 的已成功事务更新的数据。即redo log是对数据页修改后刷脏的一个有力补充。即WAL技术，Write-Ahead Logging，先写日志文件，再写到数据库页缓存，最后刷到磁盘的数据库中。

例如某一事务的事务序号为T1，其对数据X进行修改，设X的原值是5，修改后的值为15，那么Undo日志为<T1, X, 5>，Redo日志为<T1, X, 15>。

三、redo log和binlog，以及2PC

redo log是在事务进行中不断被写入，所以每个事务对应多个日志条目。

binlog 是在事务提交完成后，进行一次写入。所以对于每个事务仅仅对应一个日志记录。

redo log日志刷盘机制和参数innodb_flush_log_at_trx_commit有关。

binlog 什么时候刷新到磁盘跟参数

sync_binlog

innodb_flush_log_at_trx_commit

0: 每隔1s，由系统后台线程刷log buffer，也就是把redo日志刷盘，这里会调用fsync，所以可能丢失最后1s的事务。

1: 每次commit时，刷redo日志，确定fsync刷盘。为默认值。

2: 每次提交时，刷redo日志到文件系统，不调用fsync刷盘，5.6.6之前是每隔1s刷盘，之后的版本是通过参数innodb_flush_log_at_timeout设置，默认也是1s。所以也可能丢最后一秒的事务。如果有掉电保护组件的话，可以开启。

sync_binlog

表示每多少个sync事件触发一次真正的binlog fsync刷盘，默认是1，表示每次commit时binlog都会fsync。

建议这两个参数都设置成1.

内部XA事务与2PC

InnoDB存储引擎提供了对XA事务的支持，并通过XA事务来支持分布式事务的实现。

分布式事务（Distributed Transactions）指的是允许多个独立的事务资源（transactional resources）参与到一个全局的事务中。全局事务也必须遵循ACID原则。

XA事务允许不同数据库之间的分布式事务，例如一台MySQL数据，一台Oracle数据库，只要全局事务中的每个节点都支持XA事务即可。此时，InnoDB的隔离级别必须是SERIALIZABLE。

分布式事务采用两阶段提交（two-phase commit）的方式。

在第一阶段，所有参与全局事务的节点开始准备（PREPARE），告诉事务管理器它们准备好提交了。

在第二阶段，事务管理器告诉资源管理器执行ROLLBACK还是COMMIT。如果任何一个节点显示不能提交，则所有节点被告知需要回滚。

所以，与本地事务对比，分布式事务多了一次PREPARE操作，待收到所有节点的同意信息后，再进行提交或者回滚操作。

以上讨论的是外部事务，即资源管理器是MySQL数据库本身。而在MySQL数据库内部也可以存在这样类似的分布式事务。

资源管理器可以是存储引擎或插件，所以可以是存储引擎和插件之间，或者存储引擎与存储引擎之间，这种被称为内部XA事务。

最为常见的内部XA事务存在于binlog与InnoDB存储引擎之间。

既然是XA事务，必然涉及到两阶段提交，对于内部XA而言，同样存在着提交的两个阶段。

这个两阶段提交是在开启binlog之后，redo与binlog的两阶段提交。

在更新一条数据时，会先执行，然后写入redo log中，redo log进入prepare状态，执行器执行完成。

然后执行器生成这个操作的binlog，并写入磁盘。

然后提交commit，更新完成。

假设在任何情况下（机器掉电）mysqld crash或者os crash，MySQL仍然能保证数据库的一致性。数据的一致性是如何做到的哪？正是二阶段提交。

我们结合几种场景来分析下二阶段提交是如何做到的：

1.prepare阶段，redo log落盘前，mysqld crash

2.prepare阶段，redo log落盘后，binlog落盘前，mysqld crash

3.commit阶段，binlog落盘后，mysqld crash

对于第一种情况，由于redo没有落盘，毫无疑问，事务的更新肯定没有写入磁盘，数据库的一致性不受影响；

对于第二种情况，这时候redo log写入完成，但binlog还未写入，是提交还是回滚呢？

对于第三种情况，此时，redo log和binlog都已经落盘，只是undo状态没有更新，虽然redo log和binlog已经一致了，事务是否应该提交？

对于第三种情况，我们可以搜集到未提交事务的binlog event，所以需要提交；

对于第二种情况，由于binlog未写入，需要通过执行回滚操作来保证数据库的一致性。

简而言之，对于异常的XA事务，若binlog已落盘，则事务应该提交；binlog未落盘，则事务就应该回滚。

注：以上XA事务的2PC流程主要参考第二篇，和书上稍微有些差别，书上写的是先提交binlog，我觉得可能更合理。但是不影响对事务2PC的整体理解。 

参考资料：

《MySQL技术内幕InnoDB存储引擎》

MySQL事务提交过程（二）