MySQL (十四) 两阶段提交

一. 两阶段提交

1.1 利用 binlog 和redolog 做到两阶段提交

从上图中看出：最后提交事务的三个步骤：

1. 写入redo log ，处于prepare状态
2. 写binlog
3. 修改redo log 状态变为commit

由于redo log 的提交分为prepare 和commit两个阶段，所以我们称之为两阶段提交。

1.2 为什么要两阶段提交

假设我们不适用两阶段提交，那么binlog和redolog的提交就两种形式：

1. 先写binlog 再写redolog
2. 先写redolog 再写binlog

当我们要向表中DDL，插入一条记录R的时候。

情况一：
如果我们先写binlog再写redolog，那么假设binlog写完后崩溃了，此时redolog还没写。那么重启恢复的时候就会出现问题：
binlog中已经有R的记录了，当从主机同步数据的时候，或者我们使用binlog恢复数据的时候，就会同步R这条记录。但是redolog中没有关于R的记录，所以恢复崩溃之后，插入R记录的这个事务是无效的，即数据库中没有该行的记录，而这就造成了数据不一致的情况。

情况二：
如果我们是先写redolog再写 binlog，那么假设redolog写完后崩溃了，此时binlog还没写。那么重启恢复的时候也会出现问题：
redolog中已经有R的记录了，所以崩溃恢复之后，插入R记录的这个事务是有效的，通过该记录可以将数据恢复到数据库中；但是binlog中还没有关于R的记录，所以当从机从主机同步数据的时候，或者我们使用binlog恢复数据的时候，就不会同步到R这条记录，这就造成了数据不一致。

两阶段提交如何保证数据一致性：

情况一：一阶段提交之后崩溃了，即 写入 redo log，处于 prepare 状态 的时候崩溃了，此时：由于 binlog 还没写，redo log 处于 prepare 状态还没提交，所以崩溃恢复的时候，这个事务会回滚，此时 binlog 还没写，所以也不会传到备库。

情况二：假设写完 binlog 之后崩溃了，此时：
redolog 中的日志是不完整的，处于 prepare 状态，还没有提交，那么恢复的时候，首先检查 binlog 中的事务是否存在并且完整，如果存在且完整，则直接提交
事务，如果不存在或者不完整，则回滚事务。

情况三：假设 redolog 处于 commit 状态的时候崩溃了，那么重启后的处理方案同情况二。
由此可见，两阶段提交能够确保数据的一致性。