什么是redolog的两阶段提交呢？就是在写redolog日志的时候，并不是直接把redolog标记为完成状态。而是中间会有一个prepare状态。为了更好理解这个概念，这里我们参考下面这个SQL语句执行流程图来分析一些这个两阶段提交的含义。

从图中，我们可以看出，一条更新语句的大致执行流程是这样的：

1. server服务层的执行器，调用存储引擎层的API接口，去查询数据。
2. innodb存储引擎层查询buffer pool缓存中的数据。
3. 如果查询缓存中包含待查询的数据，则直接返回给server服务层的执行器。
4. 如果缓存中没有结果则从磁盘中去读取数据，读取数据后，再返回给server服务层，同时把查询到的数据更新到buffer pool中的数据内容。
5. server层的执行器收到查询后的数据后，执行更新操作。
6. server层调用innodb存储引擎层的API接口更新数据。
7. innodb存储引擎层更新数据到change buffer缓存池中。
8. innddb存储引擎层记录redolog，并把其状态设置为prepare状态。
9. innodb存储引擎层通知server的执行器，change buffer已经更新，redolog已经进入prepare待提交的就绪状态，可以记录binlog日志的。
10. server层的执行器记录binlog到binlog的缓冲池中。（这里缓冲池中的日志何时刷盘就是通过参数sync_binlog来控制的，下面会详细介绍。）
11. server层的执行器在记录完binlog之后，通知innodb存储引擎层，binlog已经记录完成。
12. innodb存储引擎层收到server记录完binlog的通知后，更新redolog buffer中的redolog为commit状态。（此时redolog buffer中的日志何时刷盘就是通过参数innodb_flush_log_at_trx_commit来控制的，下面会详细介绍。）

至此，整个更新语句才真正的执行完成。通过上面的过程可以看出，在记录redolog的时候，有两个过程一个是记录redolog日志，把它的状态标记为prepare待提交状态，然后等待server层的binlog日志记录完成后，才会把redolog的日志更新为commit状态。这个过程就是redolog的两阶段提交操作。我们把上面的图简化为如下的一个图，你更能看明白：

思考问题：为什么redolog要两阶段提交？

redolog的两阶段提交是实现innodb存储引擎crash-safe功能核心。它的重要性，我们可以使用反正法来解读。试想一下：如果redolog在记录的时候不是两阶段提交。那么会有什么样的后果呢？只能有以下2种情况：

1. 先写redolog，再写binlog：在一个更新操作的提交后，如果在redolog写成功之后，还没有来得及写binlog，此时发生了异常重启。由于redolog已经记录成功，所以在异常重启之后，MySQL可以根据redolog中的内容恢复到异常重启之前数据更新后的结果，但是由于binlog没有记录这个更新操作。如果日后你拿着这个binlog还原一个新库的时候，被还原的数据库中的数据就不会有这个更新操作。此时的新库和原库数据是不一致的。
2. 先写binlog，再写redolog：在一个更新操作的提交后，如果在记录完成binlog之后，还没有来记得写redolog，此时发生了异常重启。由于binlog已经记录了修改操作，所以日后在使用这个binlog还原新库的时候，被还原的库中会包含这个更新操作，但是由于redolog没有被记录，数据库在异常重启后，并不能恢复到这个更新操作之后的数据内容。此时被还原的新库和原库中的数据也是不一致的。

综上两点可以看出，不管我们先记录哪个日志，都不能够做到数据的一致性。所以，innodb存储引擎在实现的崩溃恢复crash-safe功能的时候，就巧妙的使用了这样一个所谓的两阶段提交的方式来保证数据和日志的一致性。

你可能会有这样的疑问：在redolog两阶段提交的前提下，如果在redolog记录为prepare状态之后，binlog记录完成之后，redolog还没有来得及改为commit状态的时候，也就是上面图中②和③都执行完了，但是④没有执行，此时MySQL异常重启了，会怎么样？针对这种情况，MySQL在异常重启做恢复的时候，会去比较redolog中的内容和binlog中的内容。如果发现像上面这种情况，也会认为是成功的，因为binlog已经记录，只是差redolog中的一个commit状态没有修改成功。此时在后恢复的时候，也会从redolog中恢复出来这个数据的。这样binlog中有这个修改记录，崩溃恢复后的库中也从redolog中恢复了这个修改记录。以后用binlog还原的库和原库是一致的。从业务上看，就是虽然MySQL异常重启了，但是，我们的提交成功了。

也许你又有新的疑问：在redolog两阶段提交的前提下，如果是redolog记录并且标记为prepare状态了，后续binlog没有记录，也没有修改redolog为commit状态，也就是上面图中的②执行成功了，③和④都没有成功，此时MySQL异常重启了，会怎么样？这个时候，MySQL在重启恢复的时候，也是会比较redolog和binlog中的内容，发现只有redolog的prepare状态的日志，而binlog中没有日志。此时会把这条记录视为无效的redolog日志，也就不会恢复这样的一条修改记录。从业务上看，就是MySQL的异常重启，导致了我们的提交没有成功，我们只要重新提交一次就可以了，但是这并不会影响数据的一致性。

我们知道，在很多软件设计的时候，为了提高写数据的效率，并不是直接把数据写到磁盘上，而是先写在一个缓存池buffer中。然后从buffer中再刷新到磁盘上。relaylog在写的时候也是采用类似的方式，它有一个叫做redolog buffer的缓冲池，用于存储数据，然后再从这个缓冲池中刷新数据到磁盘中。具体什么时候把数据刷新到磁盘，是有参数innodb_flush_log_at_trx_commit来控制的，该参数的默认值为1，表示每个事务在提交之后，都会立即把这个事务的redolog持久化到磁盘上的ib_logfile文件中。

参数innodb_flush_log_at_trx_commit的取值范围[0,1,2]。而每一个值所代表的刷盘的方式是不一样的，具体如下：

• innodb_flush_log_at_trx_commit=0：表示每秒钟都会把redolog写入到buffer中，然后接着会调用fsync()方法，把数据持久化到磁盘上。但是考虑到在一秒内提交的事务可能不止一个，对于一个繁忙的业务系统来说，一秒钟几十个上百个事务也是很正常的。所以如果以每秒为单位去刷新redolog到磁盘，可能会丢失一秒内已提交但是未持久化到磁盘的事务的数据。
• innodb_flush_log_at_trx_commit=1：表示每个事务提交之后就会把它的redolog写入到buffer中，然后调用fsync()方法，把事务所对应的数据持久化到磁盘上。这样可以保证在MySQL异常重启后，我们提交的事务数据不会丢失。建议这个参数的值设置为1。
• innodb_flush_log_at_trx_commit=2：表示每个事务提交之后就会把它的redolog写入到buffer中，但是不是马上就持久化该事务的redolog到磁盘上，而是每秒调用一次fsync()方法，从buffer向磁盘持久化数据到磁盘上。这样对于那些已经提交且写入到buffer中，但是还没有持久化到磁盘的事务的数据可能会丢失。

*注意：*对于上面提到的参数innodb_flush_log_at_trx_commit设置为0或者2的时候，每秒钟调用一次fsync()方法，从buffer中持久化数据到磁盘的操作，并不是100%的保证每一秒就会持久化一次。有可能大于一秒钟，也有可能一秒钟持久化多次。当有一些DDL操作或者innodb内部的一些活动的时候，此时并不会因为innodb_flush_log_at_trx_commit的值为0或者1，就按照参数设置的方式去持久化数据到磁盘，这时候可能导致一秒钟持久化了多次数据到磁盘。Anyway，在参数innodb_flush_log_at_trx_commit不是1的情况下，是有丢失数据的风险的。

事物的四大特性之一：持久性 ，在MySQL的innodb存储引擎底层来说就是靠redolog来实现的。具体来说就是只要事务提交成功，那么对数据库做的修改就被永久保存下来了，不可能因为任何原因再回到原来的状态，通过前面的介绍，我们可以知道在崩溃恢复的时候，对已经提交成功事物，就是从redolog日志文件中恢复的。所以redolog是支持事务的innodb存储引擎实现事务的持久性的方式。

redolog和binlog这两个日志经常被拿出来对比，下面我们简单列出他们之间的区别和联系。

redolog还有以下几个参数，这里简单介绍一下。

• innodb_log_group_home_dir：表示我们的redolog日志文件存放在磁盘的哪个目录下。一般情况下该值为./，表示放在当前数据目录下，即datadir参数所指向的目录。
• innodb_log_buffer_size：写redolog日志文件的时候使用的缓冲池的大小。默认为16MB。一个大的日志缓冲区允许大量的事务在提交之前不写日志到磁盘。因此，如果你有很多事务的更新，插入或删除很频繁，通过这个参数会大量的节省了磁盘I / O。

关于redolog的分析就先到这里了，如果你有什么疑问可以给我留言。我看到会及时回复你。后续我会再分析MySQL中的其他日志，敬请期待。

微信搜索『coder-home』，或者扫一扫右侧的二维码，关注『程序猿集锦』。 了解更多干货分享，还有各类视频教程。 扫描它，带走我。