MySQL(InnoDB剖析):06---Checkpoint（检查点）技术

ACID中D(持久性)的性质

• 倘若每次一个页发生变化，就将新页的版本刷新到磁盘，那么 这个开销是非常大的 。若热点数据集中在某几个页中，那么数据库的性能将变得非常差。同时，如果在从缓冲池将页的新版本刷新到磁盘时发生了宕机，那么数据就不能恢复了
• 为了 避免发生数据丢失的问题 ，当前事务数据库系统普遍都采用了Write Ahead Log策略，即 当事务提交时，先写重做日志，再修改页 。当由于发生宕机而导致数据丢失时，通过重做日志 来完成数据的恢复 。这就是事务ACID中D的要求

Sharp Checkpoint

• Sharp Checkpoint发生在 数据库关闭时将所有的脏页都刷新回磁盘 ，这是默认的工作方式，即参数innodb_fast_shutdown=1

Fuzzy Checkpoint

• 如果数据库在运行时也使用Sharp Checkpoint，那么数据库的可用性就会受到很大的影响。因此InnoDB还是用了Fuzzy Checkpoint进行页的刷新， 即只刷新一部分脏页 ，而不是刷新所有的脏页回磁盘
• Fuzzy Checkpoint会在如下几种情况发生：
  • 1.Master Thread Checkpoint
  • 2.FLUSH_LRU_LIST Checkpoint
  • 3.Async/Sync Flush Checkpoint
  • 4.Dirty Page too much Checkpoint

①Master Thread Checkpoint

• 对于Master Thread（后一篇文章会详细介绍）中发生的Checkpoint，差不多 以每秒或每十秒的速度从缓冲池的脏页列表中刷新一定比例的页回磁盘 。这个过程是异步的，即此时InnoDB存储引擎可以进行其它操作，用户查询线程不会阻塞

② FLUSH_LRU_LIST Checkpoint

• 工作原理：
  • FLUSH_LRU_LIST Checkpoint是因为InnoDB存储引擎需要 保证LRU列表中需要有差不多100个空闲页可供使用 。倘若没有100个可用空闲页，那么InnoDB 会将LRU列表尾端的页移除 ，如果这些页中 有脏页，那么需要进行Checkpoint
  • 而这些页是来自LRU列表的，因此称为FLUSH_LRU_LIST Checkpoint
• 在InnoDB 1.1.x版本之前，需要检查LRU列表中是否有足够的可用空间操作 发生在用户查询线程中，显然会阻塞用户的查询操作
• 从MySQL 5.6版本，也就是InnoDB 1.2.x版本开始，这个检查 被放在了一个单独的Page Cleaner线程中进行 ，并且用户可以通过参数innodb_lru_scan_depth 控制LRU列表中可用页的数量 ，该值默认为1024

show variables like 'innodb_lru_scan_depth'\G;

③Async/Sync Flush Checkpoint

• Async/Sync Flush Checkpoint指的是 重做日志文件不可用的情况，这时需要强制将一些页刷新回磁盘 ，而此时脏页是从脏页列表中选取的
• 若将已经写入到重做日志的LSH即为redo_lsn，将已经刷新回磁盘最新页的LSN记为checkpoint_lsn，则可定义：

• 再定义以下的变量：

• 若每个重做日志文件的大小为1GB，并且定义了两个重做日志文件，则重做日志文件的总大小为2GB。那么async_water_mark=1.5GB，sync_water_mark=1.8GB，则：
  • 当checkpoint_age<async_water_mark时： 不需要刷新任何脏页到磁盘
  • 当async_water_mark<checkpoint_age<sync_water_mark时： 触发Async Flush，从Flush列表中刷新足够的脏页回磁盘，使得刷新后满足checkpoint_age<async_water_mark
  • checkpoint_age>sync_water_mark 的情况一般很少发生，除非设置的重做日志文件太小，并且在进行类似LOAD DATA的BULK INSERT操作。此时触发Sync Flush操作，从Flush列表中刷新足够的脏页回磁盘，使得刷新后满足checkpoint_age<async_water_mark
• 由此可见， Async/Sync Flush Checkpoint是 为了保证重做日志的循环使用的可用性
• 在InnoDB 1.2.x版本之前， Async Flush Checkpoint会阻塞发现问题的用户查询线程，而Sync Flush Checkpoint会阻塞所有的用户查询线程，并且等待脏页刷新完成。 从InnoDB1.2.x版本开始 ，这部分的刷新操作同样放入到了单独的Page Cleaner Thread中，故不会阻塞用户查询线程
• MySQL官方版本并不能查看刷新页是从Flush列表中还是从LRU列表中进行Checkpoint的，也不知道因为重做日志而产生的Async/Sync Flush的次数，但是InnoSQL版本提供了方法， 可以通过下面的命令来观察：

show engine innodb status\G;

④Dirty Page too much Checkpoint

• 工作原理： Dirty Page too much，即脏页的数量太多，导致InnoDB存储引擎强制进行Checkpoint。其目的总的来说还是为了保证缓冲池中有足够可用的页
• 其可 由参数innodb_max_dirty_pages_pct控制：
  • 上面显示值为75表示， 当缓冲池中脏页的数量占据75%时，强制进行Checkpoint ，刷新一部分的脏页到磁盘。在InnoDB 1.0.x版本之前，该参数默认值为90，之后的版本都是75

show variables like 'innodb_max_dirty_pages_pct'\G;