MySQL特性两次写（double write）的在故障恢复时几种情况的分析【双写】【doublewrite buffer】

在学习MySQL双写特性的时候一直有个问题萦绕在我的心头：我们都知道MySQL在进行脏页刷新的时候会先将【内存中的doublewrite buffer】中的数据刷新到【磁盘中共享表空间的doublewrite buffer】中，然后再将脏页数据刷新到【磁盘数据文件.idb】中。当系统发生故障后MySQL可以利用undo log和来完成故障恢复工作。那么如果当系统在刷新脏页数据到【磁盘中共享表空间的doublewrite buffer】时发生了故障，且此时【磁盘中共享表空间的doublewrite buffer】不是完整页时是如何恢复数据的呢？以下是我的见解，以供参考：

首先明确一下：在没有部分写失败(partial page write)的情况下，redo log + 【磁盘数据文件.idb】即可完整的执行MySQL异常情况下的数据恢复。

考虑一种情况：如redo log 记录了52页+3条数据，此时【磁盘数据文件.idb】中有52页数据。此时如果需要将这3条数据写入【磁盘数据文件.idb】，那么这3条数据实际会组成一个新页（猜测），且此时刚好发生宕机，MySQL甚至没有机会将这3条数据组成的新页写入到磁盘（共享表空间）的doublewirte buffer中，因为没有部分写失败所以MySQL会直接使用redo log的3条数据构建一个新页写入到【磁盘数据文件.idb】中，此时的故障恢复不需要doublewrite buffer的参与。这样的话恢复的数据文件仍能保证其完整性。

第二种情况：在写入到磁盘（共享表空间）的doublewirte buffer时发生故障，导致到磁盘（共享表空间）的doublewirte buffer出现坏页。此时因为【磁盘数据文件.idb】没有坏页，恢复过程和情况第一种情况一致。

第三种情况：当写入磁盘（共享表空间）的doublewirte buffer完成，写入【磁盘数据文件.idb】时发生故障，导致【磁盘数据文件.idb】出现坏页。那么此时MySQL进行故障恢复时会使用磁盘（共享表空间）的doublewirte buffer进行恢复，因为此时磁盘（共享表空间）的doublewirte buffer已经写入完成，保存的是完整页，故也可保证的【磁盘数据文件.idb】数据的完整性，使得故障恢复正常进行。