MySQL Innodb日志机制深入分析

http://blog.csdn.net/yunhua_lee/article/details/6567869

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实际上对应日志文件的偏移量,新的LSN=旧的LSN + 写入的日志大小。举例如下:

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

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

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

1.1.1.2. Checkpoint写入

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

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

1.1.2. 管理机制

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

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

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

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

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

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

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

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

l Log flushed up to(LSN2):当前已经写入日志文件的LSN,Log flushed up to 要追上Log sequence number;

l Oldest modified data log(LSN3):当前最旧的脏页数据对应的LSN,写Checkpoint的时候直接将此LSN写入到日志文件;

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

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

具体的样例如下(使用show engine innodb status /G命令查看,Oldest modified data log没有显示):

1.1.3. 保护机制

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

l 宕机导致日志丢失 Innodb有日志刷盘机制,可以通过innodb_flush_log_at_trx_commit参数进行控制;

l 日志覆盖导致日志丢失

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点:

附注:Innodb的日志保护机制实现可以参考log0log.c文件的void log_check_margins(void)函数。

MySQL Innodb日志机制深入分析的更多相关文章

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

    版权声明:尊重博主劳动成果,欢迎转载,转载请注明出处 --爱技术的华仔 Log & Checkpoint Innodb的事务日志是指Redo log,简称Log,保存在日志文件ib_logfi ...

  2. MySQL InnoDB 日志管理机制中的MTR和日志刷盘

    1.MTR(mini-transaction) 在MySQL的 InnoDB日志管理机制中,有一个很重要的概念就是MTR.MTR是InnoDB存储擎中一个很重要的用来保证物理写的完整性和持久性的机制. ...

  3. MySQL InnoDB锁机制之Gap Lock、Next-Key Lock、Record Lock解析

    MySQL InnoDB支持三种行锁定方式: l   行锁(Record Lock):锁直接加在索引记录上面,锁住的是key. l   间隙锁(Gap Lock):锁定索引记录间隙,确保索引记录的间隙 ...

  4. Mysql Innodb 锁机制

    latch与lock latch 可以认为是应用程序中的锁,可以称为闩锁(轻量级的锁) 因为其要求锁定的时间必须要非常短,若持续时间长,则会导致应用性能非常差,在InnoDB存储引擎中,latch又可 ...

  5. MySQL InnoDB锁机制

    概述: 锁机制在程序中是最常用的机制之一,当一个程序需要多线程并行访问同一资源时,为了避免一致性问题,通常采用锁机制来处理.在数据库的操作中也有相同的问题,当两个线程同时对一条数据进行操作,为了保证数 ...

  6. MySQL- InnoDB锁机制

    InnoDB与MyISAM的最大不同有两点:一是支持事务(TRANSACTION):二是采用了行级锁.行级锁与表级锁本来就有许多不同之处,另外,事务的引入也带来了一些新问题.下面我们先介绍一点背景知识 ...

  7. MySQL Innodb表导致死锁日志情况分析与归纳

    发现当备份表格的sql语句与删除该表部分数据的sql语句同时运行时,mysql会检测出死锁,并打印出日志   案例描述在定时脚本运行过程中,发现当备份表格的sql语句与删除该表部分数据的sql语句同时 ...

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

    概要: 我们知道InnoDB采用Write Ahead Log策略来防止宕机数据丢失,即事务提交时,先写重做日志,再修改内存数据页,这样就产生了脏页.既然有重做日志保证数据持久性,查询时也可以直接从缓 ...

  9. MySQL 持久化保障机制-redo 日志

    我们在 聊一聊 MySQL 中的事务及其实现原理 中提到了 redo 日志,redo 日志是用来保证 MySQL 持久化功能的,需要注意的是 redo 日志是 InnoDB 引擎特有的功能. 为什么 ...

随机推荐

  1. Material Design系列第一篇——Creating Apps with Material Design

    Creating Apps with Material Design //创建Material Design的App Material design is a comprehensive guide ...

  2. openlayers中利用vector实现marker的方式

    项目需要一个小型的gis.openlayers,geoserver,postgres组合是比较好的选择. openlayers的marker层好像不支持拖动操作.通过研究api发现,可以利用vecto ...

  3. 【大数据系列】节点的退役和服役[datanode,yarn]

    一.datanode添加新节点 1 在dfs.include文件中包含新节点名称,该文件在名称节点的本地目录下 [白名单] [s201:/soft/hadoop/etc/hadoop/dfs.incl ...

  4. 【Shell脚本编程系列】Shell脚本开发的习惯和规范

    1.开头指定脚本解释器 #!/bin/sh或#!/bin/bash 2.开头加版本版权信息 #Date #Author #Mail #Function #Version 提示:可配置vim编辑文件时自 ...

  5. 利用腾讯云COS云对象存储定时远程备份网站

    版权声明:本文由张戈 原创文章,转载请注明出处: 文章原文链接:https://www.qcloud.com/community/article/942851001487125915 来源:腾云阁 h ...

  6. [Error: Failed to find 'ANDROID_HOME' environment variable. Try setting setting it manually

    7down voteaccepted I don't think its necessary to add everything into path.Just add the JAVA_HOME , ...

  7. C# mongohelper的初始化及账户密码设置

    MongoClientSettings mongoSettings = new MongoClientSettings(); TimeSpan t = ); mongoSettings.Connect ...

  8. LeetCode 37 Sudoku Solver(求解数独)

    题目链接: https://leetcode.com/problems/sudoku-solver/?tab=Description   Problem : 解决数独问题,给出一个二维数组,将这个数独 ...

  9. [转]RedHat Enterprise Linux 7关闭防火墙方法

    在之前的版本中关闭防火墙等服务的命令是 service iptables stop /etc/init.d/iptables stop 在RHEL7中,其实没有这个服务 [root@rhel7 ~]# ...

  10. Struts2之web元素访问与模板包含与默认Action使用

    上一篇为大家介绍了如何使用Action进行参数接收,以及简单的表单验证,本篇为大家介绍一下关于Action访问web元素的三种方式(request.session.application):模板包含( ...