了解InnoDB的Checkpoint技术(2)-木庄网络博客

不管怎样，总会后的内存页数据需要刷回到磁盘里，这里就涉及几个问题：

Write Ahead Log（预写式日志）

WAL策略解决了刷新页数据到磁盘时发生宕机而导致数据丢失的问题，它是关系数据库系统中用于提供原子性和持久性（ACID 属性中的两个）的一系列技术。

redo log，每当有事务提交时，先写入 redo log（重做日志），在修改缓冲池数据页，这样当发生掉电之类的情况时系统可以在重启后继续操作

InnoDB为了保证数据不丢失，维护了redo log。在缓冲池的数据页修改之前，需要先将修改的内容记录到redo log中，并保证redo log早于对应的数据页落盘，这就是WAL策略。

当故障发生而导致内存数据丢失后，InnoDB会在重启时，通过重放redo log，将缓冲池数据页恢复到崩溃前的状态。

按理说有了WAL策略，我们就可以高枕无忧了。但其问题点又出现在redo log上面：

所以为了解决脏页的刷新性能，脏页应该在什么时间、什么情况下进行脏页的刷新就用到了Checkpoint技术。

1、缩短数据库的恢复时间

当数据库怠机恢复时，不需要重做所有的日志信息。因为Checkpoint前的数据页已经刷回到磁盘了。只需要Checkpoint后的redo log进行恢复就好了。

2、缓冲池不够用时，将脏页刷新到磁盘

当缓冲池空间不足时，根据LRU算法会溢出最近最少使用的页，若此页为脏页，那么需要强制执行Checkpoint，将脏页也就是页的新版本刷回磁盘。

3、redo log不可用时，刷新脏页

如图redo log 的不可用是因为当前数据库对其设计都是循环使用的，所以其空间并不是无限大。

当redo log被写满, 因为此时系统不能接受更新, 所有更新语句都会被堵住。

此时必须强制产生Checkpoint需要将 write pos 向前推进，推进范围内的脏页都需要刷新到磁盘

Checkpoint发生的时间、条件及脏页的选择等都非常复杂。

Checkpoint 每次刷新多少脏页到磁盘？

Checkpoint每次从哪里取脏页？

Checkpoint 什么时间被触发？

面对上面的问题，InnoDB存储引擎内部为我们提供了两种Checkpoint：

FuzzyCheckpoint发生的情况

Master Thread Checkpoint
差不多以每秒或每十秒的速度从缓冲池的脏页列表中刷新一定比例的页回磁盘。
这个过程是异步的，即此时InnoDB存储引擎可以进行其他的操作，用户查询线程不会阻塞
FLUSH_LRU_LIST Checkpoint
因为LRU列表要保证一定数量的空闲页可被使用，所以如果不够会从尾部移除页，如果移除的页有脏页，就会进行此Checkpoint。
5.6版本后，这个Checkpoint放在了一个单独的Page Cleaner线程中进行，并且用户可以通过参数innodb_lru_scan_depth控制LRU列表中可用页的数量，该值默认为1024
Async/Sync Flush Checkpoint
指的是redo log文件不可用的情况，这时需要强制将一些页刷新回磁盘，而此时脏页是从脏页列表中选取的
5.6版本后不会阻塞用户查询
Dirty Page too much Checkpoint 即脏页的数量太多，导致InnoDB存储引擎强制进行Checkpoint。
其目的总的来说还是为了保证缓冲池中有足够可用的页。
其可由参数innodb_max_dirty_pages_pct控制,比如该值为75，表示当缓冲池中脏页占据75%时，强制进行CheckPoint