checkpoint机制,show engine innodb status

本文详细探讨了MySQL InnoDB存储引擎的checkpoint机制,包括Sharp Checkpoint和Fuzzy Checkpoint,以及其在数据库性能和一致性中的作用。通过对`show engine innodb status G`的分析,讲解了日志生成速度、脏页写入速度等关键指标,以及如何监控和调整数据库性能。还介绍了参数`innodb_fast_shutdown`和`innodb_force_recovery`在数据库恢复中的应用。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >


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中,所以不会再阻塞用户查询线程了。

这里写图片描述

<think>好的,我现在需要帮助用户理解InnoDB存储引擎中的重做日志文件组的概念和作用。首先,我应该回顾一下用户提供的引用内容,确保信息准确。 根据引用[1],重做日志文件(redo log file)对于InnoDB至关重要,记录的是每个页的物理更改情况,属于事务日志。引用[2]提到日志组中的文件大小一致,采用循环写入的方式运行,比如三个文件依次写满后循环覆盖。引用[4]指出重做日志文件大小设置对性能的影响,太大恢复时间长,太小可能导致频繁的检查点和性能抖动。 用户的问题集中在文件组的功能和结构上,我需要从这几个方面展开: 1. **功能**:重做日志文件组的主要作用是确保事务的持久性和崩溃恢复。每个事务的修改先写入redo log,而不是直接写数据文件,这样可以减少磁盘I/O,提升性能。同时,在崩溃时,通过redo log重放未持久化的修改,保证数据不丢失。 2. **结构**:文件组通常包含多个固定大小的文件(如ib_logfile0、ib_logfile1),以循环方式写入。每个文件大小相同,写满后切换到下一个,最后覆盖旧的日志。这种结构支持高效的顺序写入,避免频繁的磁盘寻道。 3. **写入机制**:循环写入意味着日志空间被重复利用。但需要考虑检查点机制,确保在覆盖前将脏页刷到磁盘,防止数据丢失。引用[4]提到的async checkpoint和capacity变量与此相关,如果检查点滞后,可能导致性能问题。 4. **性能影响**:文件大小设置需平衡恢复时间和写入性能。太大会延长恢复时间,太小则导致频繁日志切换和检查点,可能阻塞用户线程。需要根据业务负载调整innodb_log_file_size和innodb_log_files_in_group参数。 可能还需要解释为什么需要多个文件而不是单个文件。多个文件可以并行写入(虽然InnoDB通常是顺序写入),或者更容易管理日志的轮替。另外,循环写入的结构如何与LSN(日志序列号)关联,确保恢复时能正确读取。 需要确认引用中的内容是否覆盖了这些点,并正确标注引用来源。例如,循环写入的方式来自引用[2],文件大小对性能的影响来自引用[4]。同时,注意使用正确的LaTeX格式,比如变量用$innodb_log_file_size$,但根据用户指令,行内数学表达式应该用$...$,可能变量名不需要LaTeX,直接代码块或引用参数名即可。 最后,生成相关问题时要围绕文件组的结构、作用、配置优化等方面,帮助用户深入理解。例如,如何配置文件大小,循环写入的优缺点,检查点机制如何与日志文件交互等。</think>### InnoDB重做日志文件组功能与结构解析 #### 一、核心概念 重做日志文件组(Redo Log Group)是InnoDB存储引擎实现**事务持久性**和**崩溃恢复**的核心组件,由两个或多个固定大小的文件组成(默认`ib_logfile0`和`ib_logfile1`),以**循环写入**方式记录所有数据页的物理修改[^1][^2]。 #### 二、功能特性 1. **事务持久性保证** 事务提交时,修改会先写入重做日志缓冲区,再通过`fsync`系统调用持久化到日志文件组,确保即使系统崩溃也能通过日志恢复未写入数据文件的操作[^4]。 2. **崩溃恢复机制** 重启时,InnoDB通过重做日志文件组中的日志序列号(LSN)定位最后一个检查点,重放后续所有日志记录,将数据页恢复到崩溃前的状态。 3. **性能优化** 采用**顺序追加写入**模式(对比随机写入数据文件),通过`innodb_flush_log_at_trx_commit`参数可控制刷盘频率以平衡性能与可靠性。 #### 三、文件结构 | 属性 | 说明 | |------|------| | 文件数量 | 由`innodb_log_files_in_group`控制(默认2) | | 文件大小 | 由`innodb_log_file_size`定义(默认48MB) | | 写入模式 | 环形循环覆盖,日志空间利用率通过LSN控制[^2] | ```plaintext 示例日志组写入流程: ib_logfile0 → ib_logfile1 → ib_logfile0(覆盖旧日志) ``` #### 四、关键参数关联 $$ 总日志容量 = innodb\_log\_files\_in\_group \times innodb\_log\_file\_size $$ - **容量不足风险**:当日志写入速度超过刷新脏页到数据文件的速度时,会触发**同步检查点(sync checkpoint)** 导致用户线程阻塞[^4] - **优化建议**:建议设置为每小时产生日志量的1/2~1倍,可通过`SHOW ENGINE INNODB STATUS`观察`Log sequence number`变化量 #### 五、与Binlog对比 | 特性 | Redo Log | Binlog | |------|---------|--------| | 层级 | 存储引擎层 | 数据库层 | | 内容 | 物理日志(页修改) | 逻辑日志(SQL语句) | | 用途 | 崩溃恢复 | 主从复制/数据归档 | [^3]: 两者的协同通过**两阶段提交协议**实现事务一致性
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

斯言甚善

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值