本文详细解析了MySQL InnoDB中的DoubleWriteBuffer特性，包括其定义、引入原因、工作流程以及对性能的影响。重点阐述了DoubleWriteBuffer如何解决partial page write问题，确保数据一致性与安全性。
之前有阅读过相关的文档和资料，总归差了点意思，这次抽出时间仔细推敲了一下，把一些结果记录下来；
杨大师的博文给了很大的帮助：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：新年新气象~博客施工继续~
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/29510932/viewspace-1995346/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/29510932/viewspace-1995346/
扫一扫
1304
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
