InnoDB之Double write buffer

参考资料：

参考视频https://www.bilibili.com/video/BV1jA411A7qo?p=129

参考文章（墙裂推荐） https://blog.csdn.net/liuxiao723846/article/details/103509226

---

发现问题：

• 上文我们知道，InnoDB buffer pool是16kb为一页，但是操作系统从内存到磁盘是4kb为一页进行存储的。所以，InnoDB内存中的数据页，要持久化到磁盘中时，需要分成4个4KB的系统页，逐一持久化到

• 但是4个系统页从内存到磁盘的搬运并不是原子操作，所以很容易发生innoDB的数据页搬运一部分，就发生断电，宕机的情况，这种不完整的搬运页在磁盘中叫“页数据损坏”，Innodb在断电、宕机等情况后重启，进行缓存中数据恢复时，redo log是无法利用磁盘中“损坏数据页”，对缓存中数据进行恢复；

• 补充： redo log是只记录了数据页改变的部分，并没有记录整个数据页完整的镜像，所以redo log在进行内存数据的恢复时，是结合磁盘中的数据页，来还原内存中的数据页（见《深入浅出Mysql 第三版》 P304），redo log对 上述的“损坏的数据页”  是无法恢复的

 

• 如上图：P1,P2，P3为InnoDB 的3个page页，他们要持久化到磁盘需要分成4份，逐个进行持久化，但是P2在持久化过程中突然断电，导致P2.4，以及P3未持久化到磁盘中，并且P2因为只持久化一部分，变为“数据损坏页”，redo log对“数据损坏页”是无法恢复的。
• 那么Mysql在重启后进行数据恢复，将进行下面操作：

 

•  如上图：
• 因为P1已经持久化到磁盘中了，所以就不恢复了，使用的时候可以从从磁盘加载，即使是发生改变的P1.3，因为已持久化到磁盘，所以不会出问题。
• 因为P2在磁盘中是“数据损坏页”，redo log对这种持久化到一部分的页是无法恢复的，而且在需要P2时，从磁盘加载，丢失了原先改变的P2.4部分，造成脏页丢失
• 因为P3因为断电的原因，导致根本没有开始持久化，所以磁盘中的页是完整的，可以利用redo log进行恢复。

e

---

解决问题：

• Double Write Buffer  就是为了解决 redo log无法恢复未完整持久化的脏页（即数据损坏页）到缓存而诞生的；

 

 

• 具体操作如下：
• （1）buffer Pool中的数据 首先会 复制到 Double Write Buffer(简称DWB)中，大小为2M，共128页
• （2）DWB会用后台程序，将16KB的页转成4KB的页，复制到磁盘中的临时空间中，大小为2M（128页）的连续的磁盘空间，因为是顺序IO，所以速度很快；
• （3）当完全写入后，再将磁盘中临时空间的数据，写入到表空间中，完成脏页的落盘动作；

 

• 解决问题：
• 当步骤（1），（2）断电，磁盘中表空间数据并没有损坏，可以根据redo log进行恢复
• 步骤（3）属于磁盘中的写，速度很快，即使断电出现了复制一部分的页数据情况，即磁盘中临时表到磁盘中表空间数据复制了一半，突然断电停机，表空间中有了“损坏数据页”，也可以到DWB的磁盘临时空间中找到对应数据恢复到内存中；

• 总结：
• 所以double write buffer 是对redo log很好的补充，当断电宕机后，进行内存恢复时，表空间，有损坏的数据页，到DWB的磁盘临时空间找到对应数据恢复到内存中，没有损坏数据页，就用redo log进行恢复。