这篇文章将为大家详细讲解有关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的分析是怎样的就分享到这里了,希望以上内容可以对大家有一定的帮助,可以学到更多知识。如果觉得文章不错,可以把它分享出去让更多的人看到。