Redo log
WAL技术
WAL，即Write-Ahead Logging，是一种用于保证数据库事务持久性和一致性的日志记录机制。它的基本思想是在对数据库进行实际修改之前，先将修改操作记录到日志中。以确保即使在系统崩溃或故障的情况下，也能通过日志恢复数据。简单说就是先写日志，再写磁盘。
在MySQL的InnoDB存储引擎中，当我们向MySQL更新一条记录的时候，存储引擎会把记录顺序的写到redo log中，然后更新InnoDB中的buffer pool，而并不真正的更新磁盘中的数据页。等之后InnoDB存储引擎有空的时候，再把redo log中的记录刷到磁盘上，完成数据最终的持久化。
由于磁盘的顺序写入效率要远高于随机写入，并且还有组提交等优化，WAL这种方式可以大大提高更新的效率。
实现机制
Redo log是Innodb存储引擎提供的用于优化更新操作的日志。它的结构可以看成是个环形的磁盘区域。
如上图的redo log由四个文件组成，当向redo log中进行顺序写时，就是依次的写这四个文件，当写满时，就再从第一个文件开始覆盖写入。write_pos就是当前磁头的位置，一边写一边后移，checkpoint则是当前擦除的位置点，他们之间就是可以写的区域。
Redo log大小是固定的，默认是4GB(通过参数innodb_log_file_size和innodb_log_files_in_group进行配置）。Redo log不仅提高了数据更新时的效率，还让InnoDB拥有了Crash-Safe的能力，即不会因为宕机而丢数据。
和binlog的区别
redo log是InnoDB特有的，是存储引擎层的，用于crash-safe；binlog是Server层的，所有引擎都可以使用，主要用于数据归档。
redo log是物理逻辑日志，会记录数据页的位置，数据页内部则是逻辑日志，而binlog是单纯的逻辑日志，记录的就是每行的数据。
redo log有固定大小，写满了时需要进行擦除，擦除就要强制刷盘，binlog是没有大小限制的，在写到一定大小时，可以开启一个新文件接着写入。
什么是物理日志、逻辑日志、物理逻辑日志：
物理日志记录的是具体的对磁盘中数据页的操作，比如在哪个位置，做了哪个修改，只对本机有效。而逻辑日志，可以理解为SQL语句，人类是可读的。物理逻辑日志如redo log，则是物理日志和逻辑日志的结合，记录页位置时是物理的，记录数据内容时则是逻辑的。
两阶段提交
由于原本的MySQL只有MyISAM引擎，它不支持crash-safe，所以binlog也没有crash-safe的能力（因为它没有checkpoint，存储引擎不知道该从哪恢复）。而InnoDB存储引擎为了支持crash-safe，它又不能改服务器层的binlog，就增加了Redo log作为保证crash-safe的工具。而这两个日志同时存在，并且都会记录数据的更新操作，所以就需要保证两个日志文件上的记录是一致的。两阶段提交本质解决的就是redo log和binlog的数据一致性的问题。
过程
如下图是两阶段提交的过程：
InnoDB接到了Server层执行器的更新数据请求，会先将这行数据写入undolog(用于事务回滚的日志)。
然后写入InnoDB的buffer pool中。
然后将这个操作记录到redo log中，此时redo log处于Prepare状态，然后InnoDB会告知Server层的执行器，事务已经执行完，随时可以提交。
MySQL执行器在收到通知后，就会写入binlog，并调用InnoDB的接口进行提交。
最后InnoDB将刚刚写入redo log的语句置为Commit状态，本次事务就结束了。
两阶段提交的重要性
为什么给redo log设置了两个状态，而不是直接直接写redo log和binlog？
假如只是先写redo log然后再写binlog：
假如redo log写完，binlog没写完时MySQL挂了，后续恢复时，可以通过redo log恢复这次的数据，但是binlog中却没有记录，就会导致binlog中和实际数据库中存储的数据不一致。后续如果要使用这个binlog来恢复临时库的话，就会出现数据不一致。
假如只是先写binlog然后再写redo log
假如binlog写完，redolog没写时Mysql挂了，就会导致重启后无法恢复(因为redo log没有)，但是binlog中却记录了这次操作，后续使用binlog恢复临时库时，就会比源库多一次操作出来，同样导致数据不一致。
异常情况的处理
首先我们观察一下redo log在整个两阶段提交中的状态变化，然后分析一下任意一步时，MySQL异常该如何处理：
写入redo log(Prepare)
写入binlog
写入redo log(Commit)
如果在redo log的Prepare阶段到写入binlog之间MySQL宕机，此时redo log处于prepare阶段，而binlog未写入。此时MySQL重启时，发现redo log处于prepare阶段，就会检查binlog，观察到binlog中没有这条事务的记录，则会忽视这条redo log。redo log和bin log之间可以通过事务ID对应（事务ID即transaction_id，在每个事务开始时分配，递增且全局唯一）。
如果在写入binlog和redolog的Commit阶段之间MySQL宕机，则redo log仍是处于prepare阶段，但是binlog已经写入了，此时MySQL重启时，发现redo log处于Prepare阶段，就会检查binlog，观察到binlog是完整的，则会自动将这条redo log提交，并恢复数据。
总结
InnoDB引擎通过redo log实现了MySQL的Crash-Safe，再通过两阶段提交保证redo log和binlog的一致性。
两阶段提交实际上是也分布式事务的XA规范的应用，XA规范也是分布式系统维持数据逻辑一致性时的常用方案。
参考资料
[1] 极客时间《MySQL实战45讲》
评论区