InnoDB Redo Flush及脏页刷新机制深入分析

概要:

我们知道InnoDB采用Write Ahead Log策略来防止宕机数据丢失,即事务提交时,先写重做日志,再修改内存数据页,这样就产生了脏页。既然有重做日志保证数据持久性,查询时也可以直接从缓冲池页中取数据,那为什么还要刷新脏页到磁盘呢?如果重做日志可以无限增大,同时缓冲池足够大,能够缓存所有数据,那么是不需要将缓冲池中的脏页刷新到磁盘。但是,通常会有以下几个问题:

  • 服务器内存有限,缓冲池不够用,无法缓存全部数据
  • 重做日志无限增大成本要求太高
  • 宕机时如果重做全部日志恢复时间过长

事实上,当数据库宕机时,数据库不需要重做所有的日志,只需要执行上次刷入点之后的日志。这个点就叫做Checkpoint,它解决了以上的问题:

  • 缩短数据库恢复时间
  • 缓冲池不够用时,将脏页刷新到磁盘
  • 重做日志不可用时,刷新脏页

重做日志被设计成可循环使用,当日志文件写满时,重做日志中对应数据已经被刷新到磁盘的那部分不再需要的日志可以被覆盖重用。

InnoDB引擎通过LSN(Log Sequence Number)来标记版本,LSN是日志空间中每条日志的结束点,用字节偏移量来表示。每个page有LSN,redo log也有LSN,Checkpoint也有LSN。可以通过命令show engine innodb status来观察:

[plain] view plain copy

  1. ---
  2. LOG
  3. ---
  4. Log sequence number 1039878815567
  5. Log flushed up to   1039878815567
  6. Pages flushed up to 1039878814486
  7. Last checkpoint at  1039878814486
  8. 0 pending log writes, 0 pending chkp writes
  9. 5469310 log i/o‘s done, 1.00 log i/o‘s/second

Checkpoint机制每次刷新多少页,从哪里取脏页,什么时间触发刷新?这些都是很复杂的。有两种Checkpoint,分别为:

  • Sharp Checkpoint
  • Fuzzy Checkpoint

Sharp Checkpoint发生在关闭数据库时,将所有脏页刷回磁盘。在运行时使用Fuzzy Checkpoint进行部分脏页的刷新。部分脏页刷新有以下几种:

  • Master Thread Checkpoint
  • FLUSH_LRU_LIST Checkpoint
  • Async/Sync Flush Checkpoint
  • Dirty Page too much Checkpoint

Master Thread Checkpoint

Master Thread以每秒或每十秒的速度从缓冲池的脏页列表中刷新一定比例的页回磁盘。这个过程是异步的,不会阻塞查询线程。

Flush LRU List Checkpoint

InnoDB要保证LRU列表中有100左右空闲页可使用。在InnoDB1.1.X版本前,要检查LRU中是否有足够的页用于用户查询操作线程,如果没有,会将LRU列表尾端的页淘汰,如果被淘汰的页中有脏页,会强制执行Checkpoint刷回脏页数据到磁盘,显然这会阻塞用户查询线程。从InnoDB1.2.X版本开始,这个检查放到单独的Page Cleaner Thread中进行,并且用户可以通过innodb_lru_scan_depth控制LRU列表中可用页的数量,默认值为1024。

Async/Sync Flush Checkpoint

是指重做日志文件不可用时,需要强制将脏页列表中的一些页刷新回磁盘。这可以保证重做日志文件可循环使用。在InnoDB1.2.X版本之前,Async Flush Checkpoint会阻塞发现问题的用户查询线程,Sync Flush Checkpoint会阻塞所有查询线程。InnoDB1.2.X之后放到单独的Page Cleaner Thread。

Dirty Page Too Much Checkpoint

脏页数量太多时,InnoDB引擎会强制进行Checkpoint。目的还是为了保证缓冲池中有足够可用的空闲页。其可以通过参数innodb_max_dirty_pages_pct来设置,默认为75%:

[plain] view plain copy

  1. ([email protected])[(none)]> show variables like ‘innodb_max_dirty_pages_pct‘;
  2. +----------------------------+-------+
  3. | Variable_name              | Value |
  4. +----------------------------+-------+
  5. | innodb_max_dirty_pages_pct | 75    |
  6. +----------------------------+-------+
  7. 1 row in set (0.00 sec)

以上是脏页刷新的几种触发机制,接下来,细说一下日志机制及其中第3点Async/Sync
flush checkpoint原理。

 

 

Log及Checkpoint简介

Innodb的事务日志是指Redo log,简称Log,保存在日志文件ib_logfile*里面。Innodb还有另外一个日志Undo log,但Undo log是存放在共享表空间里面的(ibdata*文件)。

由于Log和Checkpoint紧密相关,因此将这两部分合在一起分析。

名词解释:LSN,日志序列号,Innodb的日志序列号是一个64位的整型。

Log写入

LSN实际上对应日志文件的偏移量,新的LSN=旧的LSN + 写入的日志大小。举例如下:

LSN=1G,日志文件大小总共为600M,本次写入512字节,则实际写入操作为:

| --- 求出偏移量:由于LSN数值远大于日志文件大小,因此通过取余方式,得到偏移量为400M;

| --- 写入日志:找到偏移400M的位置,写入512字节日志内容,下一个事务的LSN就是1000000512;

Checkpoint写入

Innodb实现了Fuzzy Checkpoint的机制,每次取到最老的脏页,然后确保此脏页对应的LSN之前的LSN都已经写入日志文件,再将此脏页的LSN作为Checkpoint点记录到日志文件,意思就是“此LSN之前的LSN对应的日志和数据都已经写入磁盘文件”。恢复数据文件的时候,Innodb扫描日志文件,当发现LSN小于Checkpoint对应的LSN,就认为恢复已经完成。

Checkpoint写入的位置在日志文件开头固定的偏移量处,即每次写Checkpoint都覆盖之前的Checkpoint信息。

 

 

Flush刷新流程及原理介绍

由于Checkpoint和日志紧密相关,将日志和Checkpoint一起说明,详细的实现机制如下:

如上图所示,Innodb的一条事务日志共经历4个阶段:

1) 创建阶段:事务创建一条日志;

2) 日志刷盘:日志写入到磁盘上的日志文件;

3) 数据刷盘:日志对应的脏页数据写入到磁盘上的数据文件;

4) 写CKP:日志被当作Checkpoint写入日志文件;

对应这4个阶段,系统记录了4个日志相关的信息,用于其它各种处理使用:

Log sequence number(LSN1):当前系统LSN最大值,新的事务日志LSN将在此基础上生成(LSN1+新日志的大小);

Log flushed up to(LSN2):当前已经写入日志文件的LSN;

Pages flushed up to(LSN3):当前最旧的脏页数据对应的LSN,写Checkpoint的时候直接将此LSN写入到日志文件;

Last checkpoint at(LSN4):当前已经写入Checkpoint的LSN;

对于系统来说,以上4个LSN是递减的,即: LSN1>=LSN2>=LSN3>=LSN4.

具体的样例如下(使用show engine innodb status \G命令查看)

[plain] view plain copy

  1. ---
  2. LOG
  3. ---
  4. Log sequence number 1039878815567
  5. Log flushed up to   1039878815567
  6. Pages flushed up to 1039878814486
  7. Last checkpoint at  1039878814486
  8. 0 pending log writes, 0 pending chkp writes
  9. 5469310 log i/o‘s done, 1.00 log i/o‘s/second

 

 

Async/Sync Flush Checkpoint原理

Innodb的数据并不是实时写盘的,为了避免宕机时数据丢失,保证数据的ACID属性,Innodb至少要保证数据对应的日志不能丢失。对于不同的情况,Innodb采取不同的对策:

1)宕机导致日志丢失

Innodb有日志刷盘机制,可以通过innodb_flush_log_at_trx_commit参数进行控制;

2)日志覆盖导致日志丢失

Innodb日志文件大小是固定的,写入的时候通过取余来计算偏移量,这样存在两个LSN写入到同一位置的可能,后面写的把前面写得就覆盖了,以“写入机制”章节的样例为例,LSN=100000000和LSN=1600000000两个日志的偏移量是相同的了。这种情况下,为了保证数据一致性,必须要求LSN=1000000000对应的脏页数据都已经刷到磁盘中,也就是要求Last checkpoint对应的LSN一定要大于1000000000,否则覆盖后日志也没有了,数据也没有刷盘,一旦宕机,数据就丢失了。

为了解决第二种情况导致数据丢失的问题,Innodb实现了一套日志保护机制,详细实现如下:

上图中,直线代表日志空间(Log cap,约等于日志文件总大小*0.8,0.8是一个安全系数),Ckp age和Buf age是两个浮动的点,Buf async、Buf sync、Ckp async、Ckp sync是几个固定的点。各个概念的含义如下:

概念 计算 含义
Ckp age LSN1- LSN4 还没有做Checkpoint的日志范围,若Ckp age超过日志空间,说明被覆盖的日志(LSN1-LSN4-Log cap)对应日志和数据“可能”还没有刷到磁盘上
Buf age LSN1- LSN3 还没有将脏页刷盘的日志的范围,若Buf age超过日志空间,说明被覆盖的日志(LSN1-LSN3-Log cap)对应数据“肯定”还没有刷到磁盘上
Buf async 日志空间大小 * 7/8 强制将Buf age-Buf async的脏页刷盘,此时事务还可以继续执行,所以为async,对事务的执行速度没有直接影响(有间接影响,例如CPU和磁盘更忙了,事务的执行速度可能受到影响)
Buf sync 日志空间大小 * 15/16 强制将2*(Buf age-Buf async)的脏页刷盘,此时事务停止执行,所以为sync,由于有大量的脏页刷盘,因此阻塞的时间比Ckp sync要长。
Ckp async 日志空间大小 * 31/32 强制写Checkpoint,此时事务还可以继续执行,所以为async,对事务的执行速度没有影响(间接影响也不大,因为写Checkpoint的操作比较简单)
Ckp sync 日志空间大小 * 64/64 强制写Checkpoint,此时事务停止执行,所以为sync,但由于写Checkpoint的操作比较简单,即使阻塞,时间也很短

当事务执行速度大于脏页刷盘速度时,Ckp age和Buf age会逐步增长,当达到async点的时候,强制进行脏页刷盘或者写Checkpoint,如果这样做还是赶不上事务执行的速度,则为了避免数据丢失,到达sync点的时候,会阻塞其它所有的事务,专门进行脏页刷盘或者写Checkpoint。

因此从理论上来说,只要事务执行速度大于脏页刷盘速度,最终都会触发日志保护机制,进而将事务阻塞,导致MySQL操作挂起。

由于写Checkpoint本身的操作相比写脏页要简单,耗费时间也要少得多,且Ckp sync点在Buf sync点之后,因此绝大部分的阻塞都是阻塞在了Buf sync点,这也是当事务阻塞的时候,IO很高的原因,因为这个时候在不断的刷脏页数据到磁盘。例如如下截图的日志显示了很多事务阻塞在了Buf sync点:

原文blog:http://blog.csdn.net/melody_mr/article/details/48930739

时间: 2024-11-05 12:24:56

InnoDB Redo Flush及脏页刷新机制深入分析的相关文章

MySQL中InnoDB脏页刷新机制Checkpoint

我们知道InnoDB采用Write Ahead Log策略来防止宕机数据丢失,即事务提交时,先写重做日志,再修改内存数据页,这样就产生了脏页.既然有重做日志保证数据持久性,查询时也可以直接从缓冲池页中取数据,那为什么还要刷新脏页到磁盘呢?如果重做日志可以无限增大,同时缓冲池足够大,能够缓存所有数据,那么是不需要将缓冲池中的脏页刷新到磁盘.但是,通常会有以下几个问题: 服务器内存有限,缓冲池不够用,无法缓存全部数据 重做日志无限增大成本要求太高 宕机时如果重做全部日志恢复时间过长 事实上,当数据库

InnoDB脏页刷新机制Checkpoint

我们知道InnoDB采用Write Ahead Log策略来防止宕机数据丢失,即事务提交时,先写重做日志,再修改内存数据页,这样就产生了脏页.既然有重做日志保证数据持久性,查询时也可以直接从缓冲池页中取数据,那为什么还要刷新脏页到磁盘呢?如果重做日志可以无限增大,同时缓冲池足够大,能够缓存所有数据,那么是不需要将缓冲池中的脏页刷新到磁盘.但是,通常会有以下几个问题: 服务器内存有限,缓冲池不够用,无法缓存全部数据 重做日志无限增大成本要求太高 宕机时如果重做全部日志恢复时间过长 事实上,当数据库

数据库日志文件和内存刷新机制

1.错误日志 error log 错误日志 error.log :记录了MySQL启动.运行.关闭过程中出现的问题. 2.慢查询日志 记录超过阀值时间的所有SQL语句,默认10s,等于10s不记. 1.5.1记录到slow_log表中. log_output参数可以指定慢查询日志输出格式,默认FILE , 可以设置成TABLE,这样就可以查看表了. 3.查询日志 记录所有日志无论是否正确执行. 4.二进制日志  binary log 记录关于事务的具体操作内容,就是对事务操作的描述,并未记录数据

MySQL · 引擎特性 · InnoDB redo log漫游(转)

前言 InnoDB 有两块非常重要的日志,一个是undo log,另外一个是redo log,前者用来保证事务的原子性以及InnoDB的MVCC,后者用来保证事务的持久性. 和大多数关系型数据库一样,InnoDB记录了对数据文件的物理更改,并保证总是日志先行,也就是所谓的WAL,即在持久化数据文件前,保证之前的redo日志已经写到磁盘. LSN(log sequence number) 用于记录日志序号,它是一个不断递增的 unsigned long long 类型整数.在 InnoDB 的日志

脏页flush和收缩表空间

mysql脏页 由于WAL机制,InnoDB在更新语句的时候,制作了写日志这一个磁盘操作,就是redo log,在内存写完redo log后,就返回给客户端, 即更新成功. 把内存里的数据写入磁盘的过程,术语就是flush,在flush之前,实际数据和数据库中的数据是不一致的,因为在redo log基础上更新了还未写入,数据库是老的,当内存数据页跟磁盘数据页内容不一致的时候,称这个内存页为脏页,内存写入后就一致了,称为干净页, 如果mysql偶尔运行速度很慢,很可能是在刷脏页.引发数据库flus

MySQL InnoDB redo Log 浅析

MySQL的InnoDB存储引引擎的物理文件存储体系中,除了实际的数据文件(ibd, ibdata)之外,还有两个非常重要的日志系统,分别是redo日志和undo日志. 跟Oracle类似, redo log记录了对实际数据文件的物理变更(数据文件的什么位置数据做了如何的变更).InnoDB也是采用了WAL(日志优先落盘),也就是说在实际数据文件的修改落盘之前redo日志已经落盘,从而来保证事务的持久性.Undo日志用来保证事务的原子性和MVCC,所有的undo操作产身的数据文件的变更也会记录到

Mysql的刷脏页问题

平时的工作中,不知道你有没有遇到过这样的场景,一条 SQL 语句,正常执行的时候特别快,但是有时也不知道怎么回事,它就会变得特别慢,并且这样的场景很难复现,它不只随机,而且持续时间还很短. 当内存数据页跟磁盘数据页内容不一致的时候,我们称这个内存页为“脏页”.内存数据写入到磁盘后,内存和磁盘上的数据页的内容就一致了,称为“干净页”. 平时执行很快的更新操作,其实就是在写内存和日志,而 MySQL 偶尔“抖”一下的那个瞬间,可能就是在刷脏页(flush). 那么,什么情况会引发数据库的 flush

【MySQL】InnoDB日志机制深入分析

版权声明:尊重博主劳动成果,欢迎转载,转载请注明出处 --爱技术的华仔 Log & Checkpoint Innodb的事务日志是指Redo log,简称Log,保存在日志文件ib_logfile*里面.Innodb还有另外一个日志Undo log Undo log是存放在共享表空间里面的(ibdata*文件). 由于Log和Checkpoint紧密相关,因此将这两部分合在一起分析. 名词解释:LSN,日志序列号,Innodb的日志序列号是一个64位的整型. 写入机制 Log写入 LSN实际上对

MySQL Innodb日志机制深入分析

1.1. Log & Checkpoint Innodb的事务日志是指Redo log,简称Log,保存在日志文件ib_logfile*里面.Innodb还有另外一个日志Undo log,但Undo log是存放在共享表空间里面的(ibdata*文件). 由于Log和Checkpoint紧密相关,因此将这两部分合在一起分析. 名词解释:LSN,日志序列号,Innodb的日志序列号是一个64位的整型. 1.1.1. 写入机制 1.1.1.1. Log写入 LSN实际上对应日志文件的偏移量,新的LS