之前有阅读过相关的文档和资料，总归差了点意思，这次抽出时间仔细推敲了一下，把一些结果记录下来；
杨大师的博文给了很大的帮助：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：新年新气象~博客施工继续~
杨大师的博文给了很大的帮助：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：新年新气象~博客施工继续~
