MySQL Innodb日志机制深入分析
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日志机制深入分析的更多相关文章
- 【MySQL】InnoDB日志机制深入分析
版权声明:尊重博主劳动成果,欢迎转载,转载请注明出处 --爱技术的华仔 Log & Checkpoint Innodb的事务日志是指Redo log,简称Log,保存在日志文件ib_logfi ...
- MySQL InnoDB 日志管理机制中的MTR和日志刷盘
1.MTR(mini-transaction) 在MySQL的 InnoDB日志管理机制中,有一个很重要的概念就是MTR.MTR是InnoDB存储擎中一个很重要的用来保证物理写的完整性和持久性的机制. ...
- MySQL InnoDB锁机制之Gap Lock、Next-Key Lock、Record Lock解析
MySQL InnoDB支持三种行锁定方式: l 行锁(Record Lock):锁直接加在索引记录上面,锁住的是key. l 间隙锁(Gap Lock):锁定索引记录间隙,确保索引记录的间隙 ...
- Mysql Innodb 锁机制
latch与lock latch 可以认为是应用程序中的锁,可以称为闩锁(轻量级的锁) 因为其要求锁定的时间必须要非常短,若持续时间长,则会导致应用性能非常差,在InnoDB存储引擎中,latch又可 ...
- MySQL InnoDB锁机制
概述: 锁机制在程序中是最常用的机制之一,当一个程序需要多线程并行访问同一资源时,为了避免一致性问题,通常采用锁机制来处理.在数据库的操作中也有相同的问题,当两个线程同时对一条数据进行操作,为了保证数 ...
- MySQL- InnoDB锁机制
InnoDB与MyISAM的最大不同有两点:一是支持事务(TRANSACTION):二是采用了行级锁.行级锁与表级锁本来就有许多不同之处,另外,事务的引入也带来了一些新问题.下面我们先介绍一点背景知识 ...
- MySQL Innodb表导致死锁日志情况分析与归纳
发现当备份表格的sql语句与删除该表部分数据的sql语句同时运行时,mysql会检测出死锁,并打印出日志 案例描述在定时脚本运行过程中,发现当备份表格的sql语句与删除该表部分数据的sql语句同时 ...
- InnoDB Redo Flush及脏页刷新机制深入分析
概要: 我们知道InnoDB采用Write Ahead Log策略来防止宕机数据丢失,即事务提交时,先写重做日志,再修改内存数据页,这样就产生了脏页.既然有重做日志保证数据持久性,查询时也可以直接从缓 ...
- MySQL 持久化保障机制-redo 日志
我们在 聊一聊 MySQL 中的事务及其实现原理 中提到了 redo 日志,redo 日志是用来保证 MySQL 持久化功能的,需要注意的是 redo 日志是 InnoDB 引擎特有的功能. 为什么 ...
随机推荐
- Material Design系列第一篇——Creating Apps with Material Design
Creating Apps with Material Design //创建Material Design的App Material design is a comprehensive guide ...
- openlayers中利用vector实现marker的方式
项目需要一个小型的gis.openlayers,geoserver,postgres组合是比较好的选择. openlayers的marker层好像不支持拖动操作.通过研究api发现,可以利用vecto ...
- 【大数据系列】节点的退役和服役[datanode,yarn]
一.datanode添加新节点 1 在dfs.include文件中包含新节点名称,该文件在名称节点的本地目录下 [白名单] [s201:/soft/hadoop/etc/hadoop/dfs.incl ...
- 【Shell脚本编程系列】Shell脚本开发的习惯和规范
1.开头指定脚本解释器 #!/bin/sh或#!/bin/bash 2.开头加版本版权信息 #Date #Author #Mail #Function #Version 提示:可配置vim编辑文件时自 ...
- 利用腾讯云COS云对象存储定时远程备份网站
版权声明:本文由张戈 原创文章,转载请注明出处: 文章原文链接:https://www.qcloud.com/community/article/942851001487125915 来源:腾云阁 h ...
- [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 , ...
- C# mongohelper的初始化及账户密码设置
MongoClientSettings mongoSettings = new MongoClientSettings(); TimeSpan t = ); mongoSettings.Connect ...
- LeetCode 37 Sudoku Solver(求解数独)
题目链接: https://leetcode.com/problems/sudoku-solver/?tab=Description Problem : 解决数独问题,给出一个二维数组,将这个数独 ...
- [转]RedHat Enterprise Linux 7关闭防火墙方法
在之前的版本中关闭防火墙等服务的命令是 service iptables stop /etc/init.d/iptables stop 在RHEL7中,其实没有这个服务 [root@rhel7 ~]# ...
- Struts2之web元素访问与模板包含与默认Action使用
上一篇为大家介绍了如何使用Action进行参数接收,以及简单的表单验证,本篇为大家介绍一下关于Action访问web元素的三种方式(request.session.application):模板包含( ...