MySQL特性两次写(double write)的在故障恢复时几种情况的分析【双写】【doublewrite buffer】

在学习MySQL双写特性的时候一直有个问题萦绕在我的心头:我们都知道MySQL在进行脏页刷新的时候会先将【内存中的doublewrite buffer】中的数据刷新到【磁盘中共享表空间的doublewrite buffer】中,然后再将脏页数据刷新到【磁盘数据文件.idb】中。当系统发生故障后MySQL可以利用undo log和来完成故障恢复工作。那么如果当系统在刷新脏页数据到【磁盘中共享表空间的doublewrite buffer】时发生了故障,且此时【磁盘中共享表空间的doublewrite buffer】不是完整页时是如何恢复数据的呢?以下是我的见解,以供参考:

首先明确一下:在没有部分写失败(partial page write)的情况下,redo log + 【磁盘数据文件.idb】即可完整的执行MySQL异常情况下的数据恢复。

考虑一种情况:如redo log 记录了52页+3条数据,此时【磁盘数据文件.idb】中有52页数据。此时如果需要将这3条数据写入【磁盘数据文件.idb】,那么这3条数据实际会组成一个新页(猜测),且此时刚好发生宕机,MySQL甚至没有机会将这3条数据组成的新页写入到磁盘(共享表空间)的doublewirte buffer中,因为没有部分写失败所以MySQL会直接使用redo log的3条数据构建一个新页写入到【磁盘数据文件.idb】中,此时的故障恢复不需要doublewrite buffer的参与。这样的话恢复的数据文件仍能保证其完整性。

第二种情况:在写入到磁盘(共享表空间)的doublewirte buffer时发生故障,导致到磁盘(共享表空间)的doublewirte buffer出现坏页。此时因为【磁盘数据文件.idb】没有坏页,恢复过程和情况第一种情况一致。

第三种情况:当写入磁盘(共享表空间)的doublewirte buffer完成,写入【磁盘数据文件.idb】时发生故障,导致【磁盘数据文件.idb】出现坏页。那么此时MySQL进行故障恢复时会使用磁盘(共享表空间)的doublewirte buffer进行恢复,因为此时磁盘(共享表空间)的doublewirte buffer已经写入完成,保存的是完整页,故也可保证的【磁盘数据文件.idb】数据的完整性,使得故障恢复正常进行。

你可能感兴趣的:(面试,mysql,数据库)