InnoDB持久化策略以及过程详解

InnoDB持久化策略以及过程详解

如果想知道InnoDB持久化策略以及过程详解方面的介绍，下面来一起了解一下吧。

InnoDB两种持久化策略

InnoDB内存部分包括缓冲池（buffer pool） 和日志缓冲（log buffer），两者刷盘方式不同，前者走direct_io模式（直接绕过Page Cache来访问磁盘），后者走Page Cache模式（IO操作需要委托操作系统来完成）。

是否使用Page Cache的区别是什么？

OS的Page Cache对读写做了不少优化，包括按顺序预读取（按页读取）、在成簇磁盘块（n次方个扇区）上执行IO、允许访问同一文件的多个进程共享高速缓存的缓冲区等，但数据必须在用户进程与内核互相拷贝。

direct_io的优点是减少操作系统缓冲区和用户地址空间的拷贝次数，降低了CPU和内存带宽的开销。而InnoDB本身也已处理好buffer pool与磁盘数据的对应关系，所以可以舍去Page Cache。

先刷buffer pool还是先刷log buffer？

先写日志，再写磁盘（WAL机制，Write-Ahead Logging），即redolog和binlog等日志数据刷盘到log文件完成后，才会将脏页从buffer pool刷盘到表文件。

为什么运用WAL机制？因为顺序写磁盘的性能堪比写内存，所以写日志会比数据刷盘的性能高很多，只要保证日志写入成功，再通过代码保证日志和需刷盘数据的一致性，就能在保证数据不丢失的情况下大大提高性能。

顺序写运用很广泛，比如kafka追加写实现了事务消息，即提交或回滚事务时，会追加写入一条控制类型的消息来标识是commit或rollback。

buffer pool持久化过程

buffer pool刷盘时机主要有以下四种：

• MySQL正常关闭之前，会把所有的脏页刷盘；
• Master Thread会以每秒或者每10秒一次的频率定期将适量的脏页刷盘。上文讲到buffer pool通过变种lru算法区分冷热数据，故后台线程会优先刷冷数据，因为热数据在短时间可能被多次修改，如果优先刷盘热数据页，这个页很快又会被修改，又需要再刷盘，不如等它变成冷数据再刷盘。
• lru空闲列表不足、log buffer或磁盘空间不足时，page cleaner线程会异步将脏页刷盘。
• buffer pool空间不足时，用户线程从磁盘读取某个页要链入lru list，lru list会释放尾部的一个页。假设这个释放的页是一个脏页，那么用户线程就不得不亲自把这个脏页刷盘，这样就会降低响应用户请求的速度。之所以需要后台线程定时刷盘脏页就是为了尽可能避免发生这种主动刷盘的情况。

InnoDB还引入了double write buffer物理存储空间，来处理buffer pool刷盘时的异常情况。buffer pool的脏页要刷盘时，数据页的空间为16KB，OS文件系统的页空间一般为4KB，磁盘的扇区每片一般为512B，最终都会一片片的刷扇区。计算机硬件和操作系统，在极端情况下（比如断电）往往并不能保证这一操作的原子性，如果16KB的数据在写入4KB时发生了系统断电/os crash，只有一部分写是成功的，这种情况写就是