原文链接：各种转载的，后面那个LSN的计算有点问题


前言:之前一直弄不清楚mysql里面bin log和innodb log文件的区别，在脑子里面一直有个疑问binlog日志文件已经可以用来进行数据库的日志备份恢复了，怎么又多了一个redo log文件了。相信也有很多人有这个疑惑，现在把整个过程文档整理出来，希望对大家有所帮忙。

如果对Oracle很了解,那么在整个学习innoDB log的时候,可以把联机重做日志的那套理论套在学习innoDB log上面,几乎是一样的;

一、innodb log的基础知识

  • innodb log顾名思义：即innodb存储引擎产生的日志，也可以称为重做日志文件，默认在innodb_data_home_dir下面有两个文件ib_logfile0和ib_logfile1。MySQL官方手册中将这两个文件叫文InnoDB存储引擎的日志文件；

  • innodb log的作用：当MySQL的实例和介质失败的时候，Innodb存储引擎就会使用innodb log文件进行恢复，保证数据库的完整性；

  • innodb log的写原理：（请容许我再放下InnoDB的原理图，并且建议把这张图看到吐）

看红色框框的那部分

  • 每个InnDB存储引擎至少有1个重做日志文件组（group），每个文件组下至少有两个重做日志文件，默认的为ib_logfile0、ib_logfile1；

  • 日志组中每个重做日志的大小一致，并循环使用；

  • InnoDB存储引擎先写重做日志文件，当文件满了的时候，会自动切换到日志文件2，当重做日志文件2也写满时，会再切换到重做日志文件1；

  • 为了保证安全和性能，请设置每个重做日志文件设置镜像，并分配到不同的磁盘上面；

（发现以上特性跟ORACLE的连接重做日志文件简直是一样的）

二、innodb log的相关参数

运行脚本：show variables like 'innodb%log%'; 查看重做日志的相关参数

mysql> show variables like 'innodb%log%';

常用设置的参数有：

innodb_mirrored_log_groups  镜像组的数量，默认为1，没有镜像；

innodb_log_group_home_dir  日志组所在的路径，默认为data的home目录；

innodb_log_files_in_group    日志组的数量，默认为2；

innodb_log_file_size              日志组的大小,默认为5M；

innodb_log_buffer_size        日志缓冲池的大小，图上为30M;

三、参数的相关调优

3.1 重做日志文件的大小设置跟ORACLE一样，面临的问题是相似的。

当innodb log设置过大的时候，可能会导致系统崩溃后恢复需要很长的时间；

当innodb log设置过小的时候，当一个事务产生大量的日志的时候，需要多次切换重做日志文件，会产生类似如下的报警；

130702 12:53:13  InnoDB: ERROR: the age of the last checkpoint is 2863217109,

InnoDB: which exceeds the log group capacity 566222311.

InnoDB: If you are using big BLOB or TEXT rows, you must set the

InnoDB: combined size of log files at least 10 times bigger than the

四、重做日志与二进制日志的区别

4.1  记录的范围不同：二进制日志会记录MySQL的所有存储引擎的日志记录（包括InnoDB、MyISAM等)，

而InnoDB存储引擎的重做日志只会记录其本身的事务日志。

4.2 记录的内容不同：二进制日志文件记录的格式可以为STATEMENT或者ROW也可以是MIXED，其记录的都是关于一个事务的具体操作内容。

InnoDB存储引擎的重做日志文件记录的关于每个页的更改的物理情况。

4.3 写入的时间也不同：二进制日志文件是在事务提交前进行记录的，而在事务进行的过程中，不断有重做日志条目被写入到重做日志文件中。



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实际上对应日志文件的偏移量，新的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个阶段：

1） 创建阶段：事务创建一条日志；

2）日志刷盘：日志写入到磁盘上的日志文件；

3） 数据刷盘：日志对应的脏页数据写入到磁盘上的数据文件；

4）写CKP：日志被当作Checkpoint写入日志文件；

 

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

Log sequence number（LSN1）：当前系统LSN最大值，新的事务日志LSN将在此基础上生成（LSN1+新日志的大小）；

Log flushed up to（LSN2）：当前已经写入日志文件的LSN；

Oldest modified data log（LSN3）：当前最旧的脏页数据对应的LSN，写Checkpoint的时候直接将此LSN写入到日志文件；

Last checkpoint at（LSN4）：当前已经写入Checkpoint的LSN；

 

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

具体的样例如下（使用show innodb status \G命令查看，Oldest modified data log没有显示）：

 

1.1.3. 保护机制

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 ageLSN1- LSN4还没有做Checkpoint的日志范围，若Ckp age超过日志空间，说明被覆盖的日志（LSN1－LSN4－Log cap）对应日志和数据“可能”还没有刷到磁盘上
Buf ageLSN1- 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日志机制深入分析

总之一点呢，innodb是先写日志再刷到磁盘中去，所以内存缓存的页数和磁盘会不一致，而重做日志就是记录缓存页的变化，就是在恢复数据到磁盘内存页时会根据redo日志的LSN自行判断从哪里将log buffer里的事务日志写入磁盘中。