mysql innodb checkpoint

  • mysql checkpoint分为两种
    • sharp checkpoint
    • fuzzy checkpoint

sharp checkpoint

sharp checkpoint会把所有已提交事务相关的脏页刷到磁盘，并记录最新的已提交事务的LSN号。sharp checkpoint刷新到磁盘的脏页是某一时刻的一致性数据。
当数据库关闭时，会发生sharp checkpoint

fuzzy checkpoint

fuzzy checkpoint则复杂很多。fuzzy checkpoint会一点点的把脏页刷新到磁盘，直到与sharp checkpoint达到相同的目的（即所有的已提交事务相关的脏页到刷到磁盘）。fuzzy checkpoint会把两个LSN之间的脏页刷新到磁盘。但是并不能保障LSN之间的数据时一致性的。所以被称为fuzzy（失真） checkpoint。
innodb使用buffer pool来避免数据直接写入磁盘。这样数据可以再buffer pool中多次修改并最终写入磁盘，这样就减少了磁盘IO。buffer pool中维护了几个重要的list：free list、LRU list、flush list。当有新的数据读入buffer pool中时，会从free list中分配page。当free list中没有空闲page时，需要等待flush list中的数据刷到磁盘，这样很慢。所以innodb会定期的把flush list中的旧数据刷到磁盘。
再者，innodb redo log文件是循环使用的，所以必须保证日志文件在重写前，所有buffer pool中相关的脏数据刷新的磁盘，不然数据库宕机后这些数据就会丢失。因为日志是按照数据修改的时间记录的，所以旧的脏数据会被先刷到磁盘，这也就是fuzzy checkpoint的工作。因为日志中的旧数据已经刷新到磁盘，所以数据库宕机后，实例恢复会从fuzzy checkpoint后的LSN开始。
当数据库正常工作时，会进行fuzzy checkpoint

时间： 2024-07-29 21:55:44

mysql innodb checkpoint的相关文章

MySQL Innodb日志机制深入分析

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

关于ORACLE 和MYSQL INNODB 触发脏数据写的机制对比

首先要说明在ORACLE和INNODB触发checkpoint方面都采用LRU进行管理,并且都有全量检查点和增量检查点一说 在MYSQL中全量检查点叫做sharp checkpoint,增量检查点叫做FUZZY CHECKPOINT, 在ORACLE中更加细化,加入了LRUW链表,并且加入CHECKPOINT-Q列表,两者共同配合完成增量CHECKPOINT,在ORACLE 中DBWR写是按照CHECKPOINT-Q的顺序写的其是LRBA的链表,其触发条件受到MTTR的限制,如果ORACL估计能

反驳＂MySQL InnoDB (不行)的性能问题＂，千万级别记录来测试说明

在 JavaEye 上看到一篇对 MySQL FUD(Fear, uncertainty and doubt) 的文章 用MySQL InnoDB Benchmark 性能测试来说明 http://www.javaeye.com/topic/34676 文中提到:"InnoDB 的磁盘性能很令人担心,MySQL 缺乏良好的 tablespace 真是天大的缺陷! --网上有用户反映存在同样的插入性能问题,百万行记录插入之后,插入速度下降到了 1/30,从开始的 1600行/秒衰退到 50行/秒-

巧用MySQL InnoDB引擎锁机制解决死锁问题

最近,在项目开发过程中,碰到了数据库死锁问题,在解决问题的过程中,笔者对MySQL InnoDB引擎锁机制的理解逐步加深. 案例如下: 在使用Show innodb status检查引擎状态时,发现了死锁问题: *** (1) TRANSACTION: TRANSACTION 0 677833455, ACTIVE 0 sec, process no 11393, OS thread id 278546 starting index read mysql tables in use 1, loc

MySQL Innodb数据库性能实践——热点数据性能

对于大部分的应用来说,都存在热点数据的访问,即:某些数据在一定时间内的访问频率要远远高于其它数据. 常见的热点数据有"最新的新闻"."最热门的新闻"."下载量最大"的电影等. 为了了解MySQL Innodb对热点数据的支持情况,我进行了基准测试,测试环境如下: [硬件配置] 硬件 配置 CPU Intel(R) Xeon(R) CPU E5620 主频2.40GHz, 物理CPU 2个,逻辑CPU 16个 内存 24G(6块 * 4G  DDR

MySQL/InnoDB和Group Commit(2)

今天发现Percona Release的Percona-Server-5-5-18-23-0已经完成了Group Commit工作,而且是用最优雅的方式(移植了MariaDB的实现,而不是workaround),心里难掩激动. 这篇文章接前篇继续介绍一下问题的背景:什么是Group Commit,现在的官方版本Group Commit做到了什么程度? 1. 什么是Group Commit MySQL/InnoDB在做事务的时候使用的日志先行(Write-ahead logging)的方式保证事务

RDS for MySQL InnoDB 行锁等待和锁等待超时的处理

RDS for MySQL InnoDB 行锁等待和锁等待超时的处理   1. InnoDB 引擎表行锁等待和等待超时发生的场景 2.InnoDB 引擎行锁等待情况的处理 2.1 InnoDB 行锁等待超时参数 innodb_lock_wait_timeout 2.2 大量行锁等待和行锁等待超时的处理 1. InnoDB 引擎表行锁等待和等待超时发生的场景 当一个 RDS for MySQL 连接会话等待另外一个会话持有的互斥行锁时,会发生 InnoDB 引擎表行锁等待情况. 通常情况下,持有该

MySQL Innodb数据库性能实践——合适的表记录数

在实际工作中,经常有同事问道:MySQL Innodb表记录数多大是合适的? 一般的理解肯定是表越大性能越低,但具体低多少呢,是缓慢下降还是急剧下降,是1000万就下降还是1亿才下降呢? 针对这些问题,我做了一下基准测试,基准测试环境如下: [硬件配置] 硬件 配置 CPU Intel(R) Xeon(R) CPU E5620 主频2.40GHz, 物理CPU 2个,逻辑CPU 16个 内存 24G(6块 * 4G  DDR3 1333 REG) 硬盘 300G * 3个,SAS硬盘 15000

MySQL Innodb数据库性能实践

在实际工作中,经常有同事问道:MySQL Innodb表记录数多大是合适的? 一般的理解肯定是表越大性能越低,但具体低多少呢,是缓慢下降还是急剧下降,是1000万就下降还是1亿才下降呢? 针对这些问题,我做了一下基准测试,基准测试环境如下: [硬件配置] 硬件 配置 CPU Intel(R) Xeon(R) CPU E5620 主频2.40GHz, 物理CPU 2个,逻辑CPU 16个 内存 24G(6块 * 4G  DDR3 1333 REG) 硬盘 300G * 3个,SAS硬盘 15000