本文共 682 字，大约阅读时间需要 2 分钟。
储引擎实现事务的通用方式是基于 redo log 和 undo log。 简单来说，redo log 记录事务修改后的数据, undo log 记录事务前的原始数据。
所以当一个事务执行时实际发生过程简化描述如下：
先记录 undo/redo log，确保日志刷到磁盘上持久存储。
更新数据记录，缓存操作并异步刷盘。
提交事务，在 redo log 中写入 commit 记录。
在 MySQL 执行事务过程中如果因故障中断，可以通过 redo log 来重做事务或通过 undo log 来回滚，确保了数据的一致性。
这些都是由事务性存储引擎来完成的，但 binlog 不在事务存储引擎范围内，而是由 MySQL Server 来记录的。
那么就必须保证 binlog 数据和 redo log 之间的一致性，所以开启了 binlog 后实际的事务执行就多了一步，如下：
先记录 undo/redo log，确保日志刷到磁盘上持久存储。
更新数据记录，缓存操作并异步刷盘。
将事务日志持久化到 binlog。
提交事务，在 redo log 中写入提交记录。
这样的话，只要 binlog 没写成功，整个事务是需要回滚的，而 binlog 写成功后即使 MySQL Crash 了都可以恢复事务并完成提交。
要做到这点，就需要把 binlog 和事务关联起来，而只有保证了 binlog 和事务数据的一致性，才能保证主从数据的一致性。
所以 binlog 的写入过程不得不嵌入到纯粹的事务存储引擎执行过程中，并以内部分布式事务（xa 事务）的方式完成两阶段提交。
转载地址：http://rdnsi.baihongyu.com/