Undo Log、Redo Log、binlog与两阶段提交

1. 什么是Undo Log？

1. 在事务ACID与隔离级别一文中我们了解到，事务的Atomicity（原子性）是通过Undo Log来实现的。
2. Undo Log其实就是在事务操作任何数据之前，先将要被覆盖的数据备份到Undo Log，然后才进行数据的修改。如果事务执行过程中出现了错误，或者用户执行了ROLLBACK操作，那么系统就可以根据Undo Log中备份的数据，将数据恢复到事务开始前的初始状态。

2. 什么是Redo Log？

1. Redo Log是InnoDB存储引擎特有的日志，位于引擎层；Redo Log 是一种物理日志，记录的是“在某个数据页上做了什么修改”；

2. 在事务ACID与隔离级别一文中我们了解到，事务的Durability（持久性）是通过Redo Log来实现的。

3. Redo Log采用了预写式日志（Write-Ahead Logging，WAL）技术。在计算机科学中，预写式日志（Write-Ahead Logging，WAL）技术是关系数据库系统中用于提供Atomicity（原子性）和Durability（持久性）的一系列技术。在使用 WAL 的系统中，所有的修改在提交之前都要先写入 log 文件中。

   1. 读和写可以完全地并发执行，不会互相阻塞（但是写之间仍然不能并发）。
   2. WAL 在大多数情况下，拥有更好的性能（因为无需每次写入时都要写两个文件）。
   3. 磁盘 I/O 行为更容易被预测。
   4. 使用更少的 fsync()操作，减少系统脆弱的问题。

4. 在事务操作数据时，将新数据备份到Redo Log，这与Undo Log刚好相反。在事务提交时，只需要在内存中将数据修改为新数据，并且将Redo Log持久化到磁盘（顺序I/O）即可，而无需将新数据直接持久化到磁盘。

5. InnoDB引擎会在适当的时候（间隔一定的时间，或者Redo Log Buffer满），将新数据按照Redo Log持久化到磁盘；

6. InnoDB 的 Redo Log 是固定大小的，比如可以配置为一组 4 个文件，每个文件的大小是 100MB，那么总共就可以记录 400MB 的操作记录。从头开始写，写到末尾就又回到开头循环写，如图所示。

7. write position 是当前记录的位置，一边写一边后移，写到第 3 号文件末尾后就回到 0 号文件开头。checkpoint 是当前要擦除的位置，也是往后推移并且循环的，擦除记录前要把记录更新到数据文件。write position 和 checkpoint 之间的是还空着的部分，可以用来记录新的操作。如果 write pos 追上 checkpoint，表示写满了，这时候不能再执行新的更新，得停下来先擦掉一些记录，把 checkpoint 推进一下。

8. 有了 Redo Log，InnoDB 就可以保证即使数据库发生异常重启，之前提交的记录都不会丢失，这个能力称为 crash-safe。

   crash-safe：
     只要更新的数据记在了Redo Log上或者磁盘上，就可以保证数据的持久性。
     本质上说，crash-safe 就是落盘处理，将数据存储到了磁盘上，断电重启也不会丢失。

3. 什么是binlog？

1. binlog 是 MySQL Server 层的日志，而不是存储引擎自带的日志，是所有存储引擎共用的。它记录了所有的 DDL 和 DML(不包含数据查询语句)语句，而且是以事件形式记录，还包含语句所执行的消耗的时间等。

2. binlog 是一种逻辑日志，他里边所记录的是一条 SQL 语句的原始逻辑，例如给某一个字段 +1，注意这个区别于 Redo Log 的物理日志（在某个数据页上做了什么修改）。

3. 之所以将binlog称为归档日志，是因为binlog不会像 Redo Log 一样擦掉之前的记录循环写，而是一直记录（超过有效期才会被清理），如果超过单日志的最大值（默认1G，可以通过变量 max_binlog_size 设置），则会新起一个文件继续记录。

4. 正是由于binlog有归档的作用，所以binlog主要用作主从同步和数据库基于时间点的还原。

5. 如果是主从模式下，binlog是必须的，因为从库的数据同步依赖的就是binlog；
   如果是单机模式，并且不考虑数据库基于时间点的还原，binlog就不是必须，因为有Redo Log就可以保证crash-safe能力了；但如果万一需要回滚到某个时间点的状态，这时候就无能为力，所以建议binlog还是一直开启；

4. 什么是两阶段提交？

1. 在实际操作中，Redo Log是分两步写的，中间穿插了binlog写；

2. 因为在主从模式下，Redo Log会影响主库的数据，而binlog会影响从库的数据，所以必须保证Redo Log与binlog的一致，否则就会造成主从数据不一致；这里的Redo Log和binlog其实就是很典型的分布式事务场景，因为两者本身就是两个独立的个体，要想保持一致，就必须使用分布式事务的解决方案来处理。而将Redo Log分成了两步，其实就是使用了两阶段提交协议（Two-phase Commit，2PC）。

3. innodb_flush_log_at_trx_commit 这个参数设置成 1 的时候，表示每次事务的 redo log 都直接持久化到磁盘。这样可以保证 MySQL 异常重启之后数据不丢失。
   sync_binlog 这个参数设置成 1 的时候，表示每次事务的 binlog 都持久化到磁盘。这样可以保证 MySQL 异常重启之后 binlog 不丢失。

5. 两阶段提交如何保证Redo Log与binlog的一致？

我们可以使用反证法。如果不是用两阶段提交，那么必然先写Redo Log或者先写binlog。

1. 如果先写Redo Log再写binlog：
   1. 假设在 Redo Log 写完，binlog 还没有写完的时候，MySQL 进程异常重启。
   2. 由于Redo Log已经提交，因此可以恢复最后一次数据提交。
   3. 但是binlog尚未将最后一次提交数据写入，因此导致不一致，binlog丢失了最近一次更新。
2. 如果先写binlog再写Redo Log：
   1. 假设在 binlog 写完，Redo Log 还没有写完的时候，MySQL 进程异常重启。
   2. 由于Redo Log尚未提交，因此崩溃恢复后。此次事务无效，最后一次数据更新不生效。
   3. 但是binlog已经将最后一次更细数据写入，因此导致不一致，binlog多记录了一次事务。

如果使用了两阶段提交：

1. 如果在Prepare阶段MySQL 进程异常重启：此时Redo Log 尚未提交，binlog也未记录该更新，两者一致；
2. 如果在Commit阶段MySQL 进程异常重启：此时Redo Log 已经prepare，且binlog也已经记录该更新，即可说明本次更新有效，将Redo Log设置为commit状态，持久化到磁盘中即可；