MySQL为什么有了redolog还需要double write buffer问题我们知道MySQL InnoDB引擎使用redolog作为异常容灾恢复的机制当MySQL进程发生异常退出、机器断电等在重新启动时使用redolog恢复。OKredolog是被MySQL设计为异常崩溃恢复的double write buffer同样是为了保证数据完整性那么既然已经有了redolog为什么还需要double write buffer双写缓冲区呢double write bufferInnoDB用double write buffer双写缓冲区来避免页没写完整所导致的数据损坏。当一个磁盘写操作不能完整地完成时不完整的页写入就可能发生16KB的页可能只有一部分被写到磁盘上。有多种多样的原因崩溃、Bug等等可能导致页没有写完整。double write buffer在这种情况发生时可以保证数据完整性。MySQL的buffer一页的大小是16K但是底层文件系统一页的大小是4K换句话说MySQL将一页buffer数据刷入磁盘需要写4个文件系统里的页。假如MySQL内page1的页准备刷入磁盘才刷了2个(p1和p2)到文件系统里的页这个时候停电或者机器宕机当机器恢复后buffer的一页数据完整性已经遭到破坏这时MySQL通过double write buffer来解决数据损坏。double write buffer是表空间一个特殊的保留区域在一些连续的块中足够保存100个页。本质上是一个最近写回的页面的备份拷贝。当InnoDB从缓冲池刷新页面到磁盘时首先把它们写或者刷新到double write buffer然后再把它们写到其所属的数据区域中。这可以保证每个页面的写入都是原子并且持久化的。如果有一个不完整的页写到了double write buffer原始的页依然会在磁盘上它的真实位置。当InnoDB恢复时它将用原始页面替换掉双写缓冲中的损坏页面。然而如果double write buffer成功写入但写到页的真实位置失败了InnoDB在恢复时将使用双写缓冲中的拷贝来替换。InnoDB知道什么时候页面损坏了因为每个页面在末尾都有校验值Checksum。校验值是最后写到页面的东西所以如果页面的内容跟校验值不匹配说明这个页面是损坏的。因此在恢复的时候InnoDB只需要读取double write buffer中每个页面并且验证校验值。如果一个页面的校验值不对就从它的原始位置读取这个页面。我们来梳理一下整个数据页落盘刷新的过程buffer数据页先copy到double write buffer的内存里double write buffer的内存数据刷到double write buffer的磁盘上double write buffer的内存再刷到数据磁盘上当MySQL出现异常崩溃时有如下几种情况发生情况一步骤1前宕机刷盘未开始数据在redo log后期可以恢复情况二步骤1后步骤2前宕机因为是在内存中宕机清空内存和情况1一样情况三步骤2后步骤3前宕机因为DWB的磁盘有完整的数据可以修复损坏的页数据由此我们可以得出结论double write buffer是针对实际的buffer数据页的原子性保证就是避免MySQL异常崩溃时写的那几个data page不会出错要么都写了要么什么都没有做。为什么redolog无法代替double write bufferredolog的设计之初是“账本的作用”是一种操作日志用于MySQL异常崩溃恢复使用是InnoDB引擎特有的日志本质上是物理日志记录的是 “ 在某个数据页上做了什么修改 ” 但如果数据页本身已经发生了损坏redolog来恢复已经损坏的数据块是无效的数据块的本身已经损坏再次重做依然是一个坏块。所以此时需要一个数据块的副本来还原该损坏的数据块再利用重做日志进行其他数据块的重做操作这就是double write buffer的原因作用。因此double write buffer与redolog对于容灾场景缺一不可。本文参考《高性能MySQL第三版》