我理解的MySQL Double Write

没有Double Write特性的时候

 

更新数据后，会将dirty page放到innodb buffer cache中。此时页的checksum值会发生变化。

页的头部fileheader部分有checksum项，名为file_page_space_or_checksum。

页的尾部filetailer部分也有用来比较checksum的项，名为file_page_end_lsn。

它们使用特殊的checksum函数来比较，以此来验证页的完整性。

这里我们简单的理解为等值比较。

 

 

这个时候执行刷新磁盘操作，16KB的页，如果只写了其中的8KB，这时候发生了意外状况，服务器掉电、MySQL示例突然停掉。这时候就会发生partial page write的问题，即只有页的部分数据同步到了磁盘上面。

checksum无法通过。

 

 

 

其实MySQL的Innodb以及Oracle数据库的redo log，不是记录纯物理的操作，而是物理和逻辑结合的日志。（这样可以减少redo的生成）

 

物理到page，也就是page具体在硬盘上的具体位置。

后面对于page的操作，则是根据自己的格式逻辑存储的（应用的时候需要通过特定的解析函数），比如说向page里面插入一条记录。

 

当然Oracle数据库也是类似的，物理，只到block级别。

 

 

所以说，当page 损坏之后，其实应用redo是没有意义的。

 

 

 

这时候无法使用redo来恢复，因为原始页已经损坏了.

会发生数据丢失。

 

 

当有doublewrite 特性以后

写脏数据到磁盘的时候，会先通过memcpy函数将dirty page拷贝到大小为2MB 的double write buffer内存区域中。

然后double write buffer第一步先将这2MB的数据每次1MB写入到共享表空间中分配的double write区域中。

第二步才将数据页写到数据文件中去。

当第二步过程中发生故障，也就是发生partial page write的问题。

 

 

先检查页内的checksum是否相同。

 

 

不一致，则直接从doublewrite中恢复。

 

 

当然，如果页的checksum通过，但是与doublewrite中的checksum不同，则可以直接应用redo log来执行恢复操作。

 

 

本文只介绍关于double write相关的内容，崩溃恢复的过程要复杂的多，想要了解更多可以到下面的链接中找到答案。

 

 

参考资料：

MySQL数据库InnoDB存储引擎Log漫游

http://www.uml.org.cn/sjjm/201205222.asp

 

Innodb Double Write

http://www.percona.com/blog/2006/08/04/innodb-double-write/

 

Configuration of the Doublewrite Buffer

http://www.percona.com/doc/percona-server/5.5/performance/innodb_doublewrite_path.html?id=percona-server:features:percona_innodb_doublewrite_path

 

InnoDB Crash Recovery 流程源码实现分析

http://hedengcheng.com/?p=183