checkpoint机制,show engine innodb status

---

show engine innodb status \G

mysql> show engine innodb status \G
---
LOG
（Innodb 事务日志相关信息，包括当前的日志序列号（Log sequence number），已经刷新同步到那个序列号，最近的check point到那个序列号了。除此之外，还显示了系统从启动到现在已经做了多少次check point，多少次日志刷新。）
---
（注：小括号为官方解释。）
Log sequence number 2560255（当前的日志序列号）
Log flushed up to   2560255（刷新到日志重做日志文件的lsn）
Pages flushed up to 2560255（写入磁盘的脏页的lsn。记录在checkpoint中）
Last checkpoint at 2560246（刷新到磁盘的lsn）
0 pending(挂起) log flushes, 0 pending chkp writes
10 log i/o's done, 0.00 log i/o's/second

解析：

• Log sequence number：日志序列号：现在已经产生到的日志量（字节）
  
  • 不同时刻的lsn的值的差值/时间差==日志的产生速度
• Log flushed up to：刷出去了多少日志
  
  • Log sequence number - Log flushed up to== 当前logbuffer的值
  • 所以，此值应<<1M
  • 不同时刻的差值/时间间隔==日志的写入速度
• Pages flushed up to
  
  • Log sequence number - Pages flushed up to 值很小，说明脏页写入的很快
• Last checkpoint at：检查点。系统启动的时候，日志恢复的起点，肯定比Pfut的值低。防止系统崩
  
  • Log flushed up to - Last checkpoint at == 系统要恢复的日志数
  • Pages flushed up to - Last checkpoint at == checkpoint的跟进速度，如果大的话，说明checkpoint需要增大。

问：有5个2个G的日志，Log flushed up to - Pages flushed up to 的值必须保证至少是多大？
答：6个G。因为，当前用着一个，必须保证想覆盖的下一个是写进去的，所以，只能是3个日志没写进去，即6个G。

---

四个参数能反应出来什么

1.日志的生成速度？

• 不同时刻的Log sequence number的值的差/时间差==每秒生成的日志量

2.日志的写入速度？

• Log flushed up to

3.脏页的写入速度？

• Log flushed up to - Pages flushed up to ==脏页的写入速度

4.数据库的启动时间是多少？

• 启动时要回滚的日志数

---

Checkpoint详解

引子

checkpoint是一个内部事件，这个事件激活以后会触发数据库写进程(DBWR)将数据缓冲(DATABUFFER CACHE)中的脏数据块写出到数据文件中。

check point是做什么的

在数据库系统中，写日志和写数据文件是数据库中IO消耗最大的两种操作，在这两种操作中写数据文件属于分散写，写日志文件是顺序写，因此为了保证数据库的性能，通常数据库都是保证在提交(commit)完成之前要先保证日志都被写入到日志文件中，而脏数据块则保存在数据缓存(buffer cache)中再不定期的分批写入到数据文件中。也就是说日志写入和提交操作是同步的，而数据写入和提交操作是不同步的。这样就存在一个问题，当一个数据库崩溃的时候并不能保证缓存里面的脏数据全部写入到数据文件中，这样在实例启动的时候就要使用日志文件进行恢复操作，将数据库恢复到崩溃之前的状态，保证数据的一致性。检查点是这个过程中的重要机制，通过它来确定，恢复时哪些重做日志应该被扫描并应用于恢复。

一般所说的checkpoint是一个数据库事件(event)，checkpoint事件由checkpoint进程(LGWR/CKPT进程)发出，当checkpoint事件发生时DBWn会将脏块写入到磁盘中，同时数据文件和控制文件的文件头也会被更新以记录checkpoint信息。

作用

checkpoint主要2个作用：

• 保证数据库的一致性，这是指将脏数据写入到硬盘，保证内存和硬盘上的数据是一样的;

• 缩短实例恢复的时间，实例恢复要把实例异常关闭前没有写出到硬盘的脏数据通过日志进行恢复。如果脏块过多，实例恢复的时间也会很长，检查点的发生可以减少脏块的数量，从而提高实例恢复的时间。

  通俗的说checkpoint就像word的自动保存一样。

Checkpoint所做的事情

将缓冲池（buffer pool）中的脏页刷回磁盘。每次刷新多少页到磁盘，每次从哪里取脏页，以及什么时间触发Checkpoint。在InnoDB存储引擎内部，Checkpoint负责这些事。

checkpoint分类

有2种Checkpoint：

• Sharp Checkpoint（完全检查点）
• Fuzzy Checkpoint（模糊检查点）

checkpoint的具体解释

1.Sharp Checkpoint（完全检查点）

数据库关闭时，会将所有的脏页都刷新回磁盘，这是默认的工作方式。参数 innodb_fast_shutdown=1

2.Fuzzy Checkpoint（模糊检查点）

但是若在数据库运行时也使用完全检查点，那数据库的可用性就会受到很大影响。
所以，在InnoDB存储引擎内部使用Fuzzy Checkpoint进行页的刷新，即只刷新一部分脏页，而不是将所有的脏页刷回磁盘。

Fuzzy checkpoint工作过程

• 先读LRU list，把一部分脏页（相对冷的）写到磁盘上；
• 再找Frush list，把最早脏的写到磁盘上。（更新检查点）

Fuzzy Checkpoint又分为4种

• ①Master Thread Checkpoint
• ②FLUSH_LRU_LIST Checkpoint
• ③Async/Sync Flush Checkpoint（异步/同步 flush检查点）
• ④Dirty Page too much Checkpoint

1）Master Thread Checkpoint

对于Master Thread 中发生的Checkpoint，差不多以每秒或每十秒的速度从缓冲池的脏页列表中刷新一定比例的页回去磁盘。这个过程是异步的，即此时InnoDB存储引擎可以进行其他的操作，用户查询线程不会阻塞。
–》即：常规性的fuzzy checkpoint，写入操作不阻塞用户线程

2）FLUSH_LRU_LIST Checkpoint

FLUSH_LRU_LIST Checkpoint是因为InnoDB存储引擎需要保证LRU列表中需要有差不多100个空闲页可供使用。在innodb1.1X版本以前，需要检查LRU列表中是否有足够的可用空间操作发生在用户查询线程中，显然会阻塞用户的查询操作。若没有100个可用空闲页，那么innodb会将LRU列表末端的页移除。如果这些页中有脏页，那就要进行Checkpoint，而这些页是来自LRU列表的，因此成为FLUSH_LRU_LIST Checkpoint。
–》即：Flush lru list checkpoint：flush list上的脏页数量超过阈值；会阻塞用户线程。

3）Async/Sync Flush list Checkpoint

（在数据库的报错日志里能够看到！）
Async/Sync Flush list Checkpoint指的是重做日志文件不可用的情况，这时需要强制将一些页刷新回磁盘，而此时脏页是从脏页列表中选取的。若将已经写入到redo log的LSN（Log sequence number）记作redo_lsn，将已经刷新回磁盘最新页的LSN记为checkpoint_lsn，则可定义：
redo_lsn - checkpoint_lsn == checkpoint_age
又定义：
async_water_mark==75% * total_redo_log_file_size
sync_water_mark==90% * total_redo_log_file_size
假设每个redo log的大小是1G，并且定义两个redo log，则redo log总共2G。
则，async_water_mark=1.5G，sync_water_mark=1.8G。则：

• ① checkpoint_age< async_water_mark 时，不需要刷新任何脏页到磁盘；
• ② **async_water_mark < checkpoint_age<
  sync_water_mark**（即：有25%的日志能被覆盖时） 时，触发Async Flush，从Async Flush
  列表中刷新足够的脏页回磁盘。最终满足①；
• ③ checkpoint_age > sync_water_mark
  时（即有90%的日志能被覆盖时），极少发生，除非设置的redo log太小，并且在进行类似LOAD DATA的BULK
  INSERT操作。此时触发Sync Flush操作，从Flush列表中刷新足够的脏页回磁盘，使得刷新后满足①。

注意：在较早版本的innodb中，Async Flush list Checkpoint会阻塞发现问题的用户查询线程，而Sync Flush list Checkpoint会阻塞所有的用户查询线程，并且等待脏页刷新完成。
但在5.6版本（即innodb1.2x版本）开始，这部分的刷新操作同样放入到了单独的Page Cleaner Thread中，所以不会再阻塞用户查询线程了。