之前有阅读过相关的文档和资料，总归差了点意思，这次抽出时间仔细推敲了一下，把一些结果记录下来；

杨大师的博文给了很大的帮助：http://blog.itpub.net/22664653/viewspace-1140915/
-------------------------------------------------------------------------------------正文------------------------------------------------------------------------------------ Double Write Buffer是什么？ 这是一个buffer， 存在于内存中， 在持久化到磁盘的时候，这一部分数据会 写进 innodb的表空间里，由一段连续的pages组成； Double Write这个特性，和命名所描述的完全一致： 写两遍~ 为什么要引入Double Write Buffer？ 引入 Double Write Buffer是为了 解决 partial page write 的问题 ，关于这个问题的描述， 引用杨大师的原文， >>> InnoDB 的Page Size一般是16KB，其数据校验也是针对这16KB来计算的，将数据写入到磁盘是以Page为单位进行操作的。

而计算机硬件和操作系统，在极端情况下（比如断电）往往并不能保证这一操作的原子性，

16K的数据，写入4K 时，发生了系统断电/os crash ，只有一部分写是成功的，这种情况下就是 partial page write 问题。

<<<

追问1：抛开page不完全写入的这个概念，DB在做crash recovery的时候，不是可以从redo log来重新做一遍么，为什么还要这个特性呢？

解答：原因有两个，

1.由于Page的不完全写入，实际上这个出问题的Page由于没有完全写入，所以这个page的checksum是无效的，想恢复这个page的时候，无法定位是哪个page写出了问题；

2.redo-log的原因， MySQL的innodb在生成redo-log的时候，并没有写入具体数据的变更，而是只记录了这个变更所在的page信息，具体的格式如下

    [Space-id] [Page-id] [Where-in-the-page-to-modify] [Payload]

其中，space-id记录的是这个信息存储于哪个redo-log文件，page-id记录的就是page的id（..._(:з」∠)_...），其余信息基本如描述所示；

由于redo-log的这种记录方式，使得MySQL不能依靠redo-log去把崩溃前后一段时间的整个事务全部找出来，然后重做；（存都没存数据，怎么恢复嘛╮(╯▽╰)╭）；

Double Write Buffer工作在哪个阶段/时机？ 当innodb从buffer pool中刷新pages到磁盘时，并不是直接往磁盘写，而是 先写进这个 Double Write Buffer， 然后马上调用fsync()，将这一部分数据写到磁盘上， 之后再把这部分的pages写到真正的数据文件里面去； Double Write Buffer能不能解决问题？ 答案肯定是可以~ 情景1：innodb 从buffer pool往 Double Write Buffer写pages的时候，出事故了，发生了page的部分写入； 分析：innodb在crash recovery的时候，检查到 数据文件的pages都是正常的 ，通过比较LSN/checksum能够检查到数据文件的具体状态，然后再去恢复数据； 情景2： 从 Double Write Buffer往真正的数据文件 写pages的时候，出事故了，发生了page的部分写入； 分析： 由于 Double Write Buffer本身有这个pages的完整内容，从 Double Write Buffer重新往数据文件写pages即可； Double Write Buffer对性能的影响？ 由于 Double Write Buffer本身是一段完全连续的空间，所以 Double Write Buffer从内存写到磁盘的时候 是完完全全的顺序写， 所以对性能的影响并没有从1个fsync()到2个fsync()这么夸张， 引用percona的工程师的判断：性能影响不超过5%-10%； -------------------------------------------------------------------------------------结尾------------------------------------------------------------------------------------

PS：MySQL的crash recovery不仅依靠了redo log，应该还有binlog的功劳在里面，不过这方面了解的不是很清晰，挖个坑，以后推敲......坑坑坑

PPS：新年新气象~博客施工继续~