【MySQL】双写、重做日志对宕机时脏页数据落盘的作用的疑问及浅析

众所周知，双写机制、重做日志文件是mysql的InnoDB引擎的几个重要特性之二。其中两者的作用都是什么，很多文章都有分析，如，双写机制（Double Write）是mysql在crash后恢复的机制，而重做日志文件（Redo Log File）也是mysql崩溃恢复机制的一部分。但是，这两者是如何保证mysql能够正确恢复数据的呢？对此，我在看书查证和思考过程中，产生了很多的疑问，也有一些收获，写在下面。

一，介绍双写机制、重做日志文件

首先，我先介绍或者说概括一下双写机制，和重做日志文件。在《MySQL技术内幕 InnoDB技术引擎》[1]一书中，双写机制部分介绍原文如下：

如果说Insert Buffer带给InnoDB存储引擎的是性能上的提升，那么doublewrite（两次写）带给InnoDB存储引擎的是数据页的可靠性。
当发生数据库宕机时，可能InnoDB存储引擎正在写入某个页到表中，而这个页只写了一部分，比如16kb的页，只写了前4kb，之后就发生了宕机，这种情况被成为部分写失效（partial page write）。在InnoDB存储引擎未使用doublewrte技术前，曾经出现过因为部分写失效而导致数据丢失的情况。
有经验的DBA也许会想，如果发生写失效，可以通过重做日志进行恢复。这是一个办法，但是必须清楚的意识到，重做日志中记录的是对页的物理操作，如偏移量800，写’aaa’记录。如果这个页本身已经发生了损坏，再对其进行重做是没有意义的。这就是说，在应用（apply）重做日志之前，用户需要一个页的副本，当写入失效发生时，先通过页的副本来还原该页，再进行重做，这就是doublewrite。在InnoDB存储引擎中doublewrite的体系架构如图2-5所示。
doublewrite由2部分组成，一部分是内存中的doublewrite buffer，大小为2MB，另一部分是物理磁盘上共享表空间中连续的128个页，即2个区（extent），大小同样为2MB。在对缓冲池的脏页进行刷新时，并不直接写磁盘，而是会通过memcpy函数将脏页先复制到内存中的doublewrite buffer，之后通过do