Checkpoint 技术
前篇 InnoDB 体系架构 (二) 内存 从缓冲池缓冲池的管理重做日志缓冲额外内存缓冲这四个点介绍了 InnoDB 存储引擎的内存结构, 而在将缓冲池的数据刷新到磁盘的过程中使用到了 Checkpoint 技术, 这篇文章我们着重讲解一下 Checkpoint 在内存中到应用
一 Checkpoint 使用背景
由于日常 DML 语句, 如: Update / Delete 操作首先操作了缓冲池的数据, 并没有立即写入到磁盘, 这有可能会导致内存中数据与磁盘中的数据产生不一致的情况而与磁盘数据不一致的缓冲池的页就是我们常说的脏页而 checkpoint 的工作, 就是将内存中的脏页, 在一定条件下将脏页刷新到磁盘
如果在从缓冲池将页数据刷新到磁盘的过程中发生宕机, 那么数据就无法恢复了; 为了避免这种情况的发生, 采用了 Write Ahead Log 策略, 即当事务提交时, 先写重做日志, 再修改页, 这样发生宕机也可以通过重做日志进行恢复
二 Checkpoint 的目的
1. 如果重做日志太大, 那么数据库启动的时候恢复时间过长;
2. 缓冲池不够用时, 需要先将脏页数据刷新到磁盘中;
3. 重做日志不可用时, 刷新脏页到磁盘;
三 Checkpoint 的运作机制
在了解运作机制之前, 先来思考一下这几个问题: Checkpoint 发生的时间? 发生的条件? 脏页 (对象) 的选择?
在 InnoDB 存储引擎内部, Checkpoint 分为了两种:
(一) Sharp Checkpoint
Sharp Checkpoint 发生在数据库关闭时, 将所有的脏页都刷新回磁盘, 这是默认的工作方式, 参数: innodb_fast_shutdown=1
(二)Fuzzy Checkpoint
在 InnoDB 存储引擎运行时, 使用 Fuzzy Checkpoint 进行页刷新, 只刷新一部分脏页在以下四种情况下会出发 Fuzzy Checkpoint:
1. Master Thread Checkpoint
对于 Master Thread, 以每秒或者每 N 秒的速度将缓冲池的脏页列表刷新一定比例的页回磁盘, 这个过程是异步的, 用户查询线程不会阻塞
2. FLUSH_LRU_LIST Checkpoint
为了保证 LRU 列表中有 100 个左右的空闲页可使用, 在 InnoDB 1.1.x 版本之前, 用户查询线程会检查 LRU 列表是否有足够的空间操作如果没有, 根据 LRU 算法, 溢出 LRU 列表尾端的页, 如果这些页有脏页, 需要进行 checkpoint 因此叫: FLUSH_LRU_LIST Checkpoint
3. Async/Sync Flush Checkpoint
Async/Sync Flush checkpoint 发生在重做日志不可用的时候(满了), 将 buffer pool 中的一部分脏页刷新到磁盘中, 在脏页写入磁盘之后, 事物对应的重做日志也就可以释放了关于 redo_log 文件的的大小, 可以通过 innodb_log_file_size 来配置
4. Dirty Page too much Checkpoint
即脏页太多, 强制 checkpoint, 保证缓冲池有足够可用的页
参数设置: innodb_max_dirty_pages_pct = 75 表示: 当缓冲池中脏页的数量占 75% 时, 强制 checkpoint1.0.x 之后默认 75
来源: http://www.bubuko.com/infodetail-2532522.html