如果说 Insert Buffer带给 InnoDB存储引擎的是性能上的提升,那么 double write(两次写)带给 InnoDB存储引擎的是数据页的可靠性。
当发生数据库宕机时,可能 InnoDB存储引擎正在写入某个页到表中,而这个页只写了一部分,比如16KB的页,只写了前4KB,之后就发生了宕机,这种情况被称为部分写失效(partial page write)。在 InnoDB存储引擎未使用 doublewrite技术前,曾经出现过因为部分写失效而导致数据丢失的情况。
有经验的DBA也许会想,如果发生写失效,可以通过重做日志进行恢复。这是个办法。但是必须清楚地认识到,重做日志中记录的是对页的物理操作。如果这个页本身已经发生了损坏,再对其进行重做是没有意义的。这就是说,在应用重做日志前,用户需要一个页的副本,当写入失效发生时,先通过页的副本来还原该页,再进行重做,这就是 doublewrite。在 InnoDB存储引擎中doublewrite的体系架构如图所示。
由于innodb page是16K，一般系统page是4k,当有个update语句需要对业内记录加1，当第一个4k中记录加1后，系统宕机，重启恢复时候，innodb 不知道从哪里给记录加1，如果给16k里所有记录都加1，就会导致第一个4k里面记录加2，必然导致数据不一致，这个时候double write buffer就解决了这个问题。
Double Write的思路很简单:
A. 在覆盖磁盘上的数据前，先将Page的内容写入到磁盘上的其他地方(InnoDB存储引擎中的doublewrite buffer，这里的buffer不是内存空间，是持久存储上的空间).
B. 然后再将Page的内容覆盖到磁盘上原来的数据。
如果在A步骤时系统故障，原来的数据没有被覆盖，还是完整的。
如果在B步骤时系统故障，原来的数据不完整了，但是新数据已经被完整的写入了doublewrite buffer. 因此系统恢复时就可以用doublewrite buffer中的新Page来覆盖这个不完整的page。
doublewrite由两部分组成,一部分是内存中的 doublewrite buffer,大小为2MB,另部分是物理磁盘上共享表空间中连续的128个页,即2个区( extent),大小同样为2MB。在对缓冲池的脏页进行刷新时,并不直接写磁盘,而是会通过 memcpy函数将脏页先复制到内存中的 doublewrite buffer,之后通过 doublewrite buffer再分两次,每次1MB顺序地写入共享表空间的物理磁盘上,然后马上调用 fsync函数,同步磁盘,避免缓冲写带来的问题。在这个过程中,因为 doublewrite页是连续的,因此这个过程是顺序写的,开销并不是很大。在完成 doublewrite页的写入后,再将 doublewrite buffer中的页写入各个表空间文件中,此时的写入则是离散的。可以通过以下命令观察到 doublewrite运行的情况:
mysql>SHOW GLOBAL STATUS LIKE 'innodb dblwr%'\G
可以看到, doublewrite一共写了6325194个页,但实际的写入次数为100399,基本上符合64:1。如果发现系统在高峰时的 Innodb dblwr_pages_written:Innodb_dblwr_writes远小于64:1,那么可以说明系统写入压力并不是很高。
如果操作系统在将页写入磁盘的过程中发生了崩溃,在恢复过程中, InnoDB存储引擎可以从共享表空间中的 doublewrite中找到该页的一个副本,将其复制到表空间文件再应用重做日志。下面显示了一个由 doublewrite进行恢复的情况:
若查看MyQL官方手册,会发现在命令 SHOW GLOBAL STATUS中 Innodb_buffer_pool_pages_flushed变量表示当前从缓冲池中刷新到磁盘页的数量。根据之前的介绍,用户应该了解到,在默认情况下所有页的刷新首先都需要放入到 doublewrite中,因此该变量应该和 Innodb_dblwr_pages_written一致。然而在 MySQL5.5.24版本之前,Innodb_buffer_pool_pages_flushed总是为 Innodb_dblwr_pages_written的2倍,而此Bug直到 MySQL5.5.24才被修复。因此用户若需要统计数据库在生产环境中写入的量,最安全的方法还是根据 Innodb_dblwr_pages_written来进行统计,这在所有版本的 MySQL数据库中都是正确的。
参数 skip_innodb_doublewrite可以禁止使用 doublewrite功能,这时可能会发生前面提及的写失效问题。不过如果用户有多个从服务器(slave server),需要提供较快的性能(如在slaves server上做的是RAID0),也许启用这个参数是一个办法。不过对于需要提供数据高可靠性的主服务器(master server),任何时候用户都应确保开启doublewrite功能。
注意： 有些文件系统本身就提供了部分写失效的防范机制,如ZFS文件系统。在这种情况下,用户就不要启用 doublewrite了。
