如图，如果操作系统在将页写入磁盘的过程中发生了崩溃，在恢复过程中，InnoDB存储引擎可以从共享表空间中的Double write中找到该页的一个副本，将其复制到表空间文件，再应用重做日志。
下面显示了一个由Double write进行恢复的情况：
090923 12:36:32 mysqld restarted 090923 12:26:33 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Crash recovery may have faild for some .ibd files! InnoDB: Restoring possible half-written data pages from the doublewrite. InnoDB: buffer... Double Write 的问题Double write buffer 它是在物理文件上的一个buffer, 其实也就是file，所以它会导致系统有更多的fsync操作，而因为硬盘的fsync性能问题，所以也会影响到数据库的整体性能。
Double write页是连续的，因此这个过程是顺序写的，开销并不是很大。
在完成Double write页的写入后，再将Double write buffer中的页写入各个数据文件中，此时的写入则是离散的
总结
当commit 一个修改语句时，如果redo log有空闲区域，直接写redo log，如果redo log没有空闲区域，那么需要把被覆盖的redo log对应的数据页刷新到data file 中，最后改pool buffer中的记录
innodb的redo log 不会记录完整的一页数据，因为这样日志太大，它只会记录那次（sequence）如何操作了（update,insert）哪页(page)的哪行(row)
因为数据库使用的页（page，默认16KB）大小和操作系统对磁盘的操作页（page，默认4KB）不一样，当提交了一个页需要刷新到磁盘，会有多次IO， 此时刷了前面的8k时异常发生宕机。在系统恢复正常后，如果没有double write机制，此时数据库磁盘内的数据页已损坏，无法使用redo log进行恢复。
如果有double write buffer，会检查double writer的数据的完整性，如果不完整直接丢弃double write buffer内容，重新执行那条redo log，如果double write buffer的数据是完整的，用double writer buffer的数据更新该数据页，跳过该redo log。
