阅读mysqlcheckpoint文档
This commit is contained in:
@@ -201,4 +201,31 @@ checkpoint解决了如下问题:
|
||||
### redo log不可用
|
||||
redo log类似循环队列,checkpoint之前的位置都已经被刷新到磁盘中,可以被覆盖使用。如果当redo log文件中所有的内容都未被刷新到磁盘中,那么此时会强制触发checkpoint。
|
||||
|
||||
### LSN
|
||||
checkpoint代表的是`最后被写入到磁盘文件中的变更`,通过LSN来进行表示。
|
||||
|
||||
LSN为Log Sequence Number,该值不断递增,代表了和`redo log`中操作记录相关的时间点。(LSN代表的时间点和事务的开始和结束时间并不相关,LSN可以处于一个或多个事务的中间)。
|
||||
|
||||
LSN在innodb内部被使用,用于`crash recovery`和管理缓冲池。LSN长度为8字节,
|
||||
|
||||
### Fuzzy Checkpoint
|
||||
innodb中实现了fuzzy checkpoint机制,会基于小批量(small batches)来将buffer pool中的页刷新到磁盘中。`并不需要在一次batch中将buffer pool中的页都刷新到磁盘中,否则checkpoint过程会中断用户的sql语句处理`。
|
||||
|
||||
在`crash recovery`的过程中,innodb会查找已经写入到log file中的checkpoint,位于checkpoint之前的内容已经被全部写入到数据库的磁盘文件中,innodb会扫描checkpoint之后的内容,并且将log file中的修改都应用到数据库中。
|
||||
|
||||
|
||||
### checkpoint种类
|
||||
innodb内部使用Fuzzy Checkpoint进行页的刷新,只会将一部分的脏页刷新到磁盘。
|
||||
|
||||
innodb中存在如下集中类型的fuzzy checkpoint:
|
||||
- Master Thread Checkpoint
|
||||
- FLUSH_LRU_LIST_CHECKPOINT
|
||||
- Async/Sync Checkpoint
|
||||
- Dirty Page Too Much Checkpoint
|
||||
|
||||
#### Master Thread Checkpoint
|
||||
在Master Thread,大约以固定的间隔将一定比例的脏页刷新到磁盘中。Master Thread刷新脏页的操作是异步的,用户线程并不会因之阻塞。
|
||||
|
||||
#### FLUSH_LRU_LIST_CHECKPOINT
|
||||
在innodb中,需要保证LRU中有一定数量的空闲页,如果空闲页少于该数量,那么innodb会将位于LRU尾端的页面淘汰。如果被淘汰页中存在脏页,那么对这些脏页需要执行checkpoint操作。
|
||||
|
||||
|
||||
Reference in New Issue
Block a user