MySQL中Double Write Buffer的分析是怎样的

这篇文章将为大家详细讲解有关MySQL中Double Write Buffer的分析是怎样的，文章内容质量较高，因此小编分享给大家做个参考，希望大家阅读完这篇文章后对相关知识有一定的了解。

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%；

关于MySQL中Double Write Buffer的分析是怎样的就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。