我们知道数据的修改首先是在Buffer Pool中进行的,之后再定时刷到磁盘中。那么如果在事务提交后还没刷新到磁盘中,系统就崩溃了,那么此时数据就丢失了,这就不满足事务的持久性了。而如果我们考虑每次提交之后,都同步将事务中所有的页面刷新到磁盘,这样确实可以保证持久性,但是这种方法存在以下两种问题:
我们只是希望这个提交的事务的修改不会丢失,即使崩溃在重启后也可能进行恢复,那么其实完全没有必要在每次提交的时候就将页面全部刷回去,只需要对修改的内容简单的做一个记录就可以了。因此InnoDB引入了redo log重做日志,其具有很多种类型,但是大多都有如下的通用结构:
事务提交时只刷新redo log到磁盘的好处:
对页面的修改是极其简单的情况下,redo日志只需要记录一下某个页面的某个偏移量处修改了几个字节的值、具体修改后的内容是啥就好了。InnoDB根据写入数据的多少划分了几种不同的redo日志:
MLOG_1BYTE、MLOG_2BYTE、MLOG_4BYTE、MLOG_8BYTE这四种类型的日志结构相似,只是具体数据包含的字节数量不同罢了。MLOG_WRITE_STRING类型的redo日志表示写入一个字节序列,但是因为不能确定写入的具体数据占用多少字节,所以还需要添加一个len字段。
在把一条记录插入到一个页面时,可能需要更改的地方非常多(比如修改数据页的Page Header、Page Diretory中的槽信息、上一条记录的next_record属性等等),如果使用前面简单的日志类型,那么要么产生很多条redo日志(在每处修改的地方都产生一条),要么产生一条记录,将页面第一个被修改的字节到最后一个被修改的字节之间的所有数据都记录下来。但显然这两种方式都有明显的缺点,因此InnoDB引入了复杂的日志类型:
还有很多类型就不一一列举了。这些类型的redo日志既包含物理层面的意思,也包含逻辑层面的意思:
MySQL把对底层页面进行一次原子访问的过程称为一个Mini-Transaction(MTR),比如向某个索引对应的B+树中插入一条记录的过程就是一个MTR。每个SQL语句可能会包含多个MTR,比如插入语句包含对聚簇索引对应的B+树插入数据,也包含对其他二级索引对应的B+树插入数据等多个对页面的原子访问过程。而一个MTR可能会包含多条redo日志,比如说对一棵B+树执行插入记录操作时,可能涉及对系统页面的改动、修改各种段、区的统计信息、修改各种链表的统计信息等,因此会产生很多的redo日志。我们显然不能说一个插入操作对应的对各种页的修改执行一半就停止了(即有的页修改了有的页没修改,那显然就会出现错误),所以在进行崩溃恢复时,我们需要把每个MTR对应的多条redo日志当为一组不可分割的整体来处理。
为了保证这些操作的原子性,必须以组的形式来记录redo日志。在进行恢复时,针对某个组的redo日志,要么全部恢复,要么一条也不恢复。为了实现这个功能,InnoDB在每组的最后一条redo日志后面加上一条特殊类型的redo日志。这个类型称为MLOG_MULTI_REC_END,它的结构很简单,只有一个type字段。
所以某个需要保证原子性的操作产生的一系列redo日志,必须以一条类型为MLOG_MULTI_REC_END的redo日志结尾。这样在进行数据恢复时,只有解析到这条日志才认为解析到了一组完整的redo日志,才会进行恢复,否则直接放弃前面解析到的redo日志。
为了更好地管理redo日志,InnoDB将MTR生成的redo日志都放在了大小为512字节的页中,一个redo页(又称redo log block)的组成如下:
log block header(12字节)
log block body(496字节):存放redo日志
log block trailer(4字节)
为了解决磁盘速度过慢的问题,redo日志也引入了缓冲区,称为redo log buffer。这片连续的内存空间被划分为若干个连续的redo log block。
此外InnoDB还提供了一个称为buf_free的全局变量,用来指明后续写入的日志应该写到log buffer中的那个位置。
在MTR执行过程中可能会产生若干条redo日志,这些redo日志是一个不可分割的组,所以并不是没生成一条redo日志就将其插入到log buffer中,而是将每个MTR运行过程中产生的日志先暂存到一个地方,等MTR结束时再将这一组redo日志全部复制到log buffer中。
此外不同的事务可能是并发执行的,因此不同MTR对应的redo日志可能是交替写入log buffer的。
log buffer空间不足:如果当前写入log buffer的redo日志量占满了log buffer总容量的50%左右,就需要把这些日志刷新到磁盘
事务提交:为了保证持久性,必须再事务提交时把对应的redo日志刷新到磁盘。可以通过innodb_flush_log_at_trx_commit
参数选择为其他策略
在脏页刷新到磁盘之前,会保证先将其对应的redo日志刷到磁盘
后台线程定时刷新:大约以每秒一次的频率刷新
正常关闭服务器
做checkpoint
MySQL的数据目录下默认有名为ib_logfile0和ib_ligfile1的两个文件,log buffer中的日志在默认情况下就是刷新到这两个磁盘文件中。磁盘上的redo日志文件是以一个日志文件组的形式出现的,组内有多少个日志文件可以进行设置。在redo日志写入日志文件组时,首先从ib_logfile0开始写,之后接着ib_logfile1,直至最后一个文件也写满了,就重新回到ib_logfile0继续写,即采用循环写的方式。
在redo日志文件组中,每个文件的大小都一样,格式也一样,都是由一下两部分组成:
log file header:描述该redo日志文件的一些整体属性
checkpoint1
checkpoint2:结构同checkpoint1
自系统运行开始,就在不断地修改页面,不断的产生redo日志。redo日志的量在不断递增,永不会缩减。因此InnoDB引入了一个名为**lsn(log sequence number)的全局变量,用来记录当前总共已经写入的redo日志量,也就是说lsn越小,日志产生的越早。**lsn的初始值为8704,即一条redo日志也没写入时,lsn的值就是8704。
在向log buffer中写入redo日志时并不是一条条写入的,而是以MTR生成的一组redo日志为单位写入的,并且写入到的是log block body处。但是在统计lsn的增长量时,其实不只是统计当前redo日志的字节数,还会去加上这个MTR额外占用的log block header和log block trailer的字节数。
系统在第一次穷后,在初始化log buffer时,buf_free就会指向第一个block的偏移量为12字节的地方,lsn也会跟着增加12。接着当插入redo日志时,如果带插入的block剩余的空间能够容纳这个MTR提交的日志组,那么lsn就只需要加上这组日志占用的字节数。如果超过了,那么其会使用到下一个block,因此还需要加上这个MTR覆盖的log block header和log block trailer占用的字节数。如果跨过了一个block,则加上12+4个字节。
redo日志是先写到log buffer之后才会被刷新到磁盘的redo日志文件中,所以lsn表示的日志包括了写到log buffer但是没有刷新到磁盘的redo日志。因此InnoDB引入了一个名为flushed_to_disk_lsn的全局变量用来表示刷新到磁盘中的redo日志量。
在系统第一次启动时,该变量的值与初始的lsn是相同的,都是8704,。随着系统的运行,redo日志不断地被写入到log buffer,但是并不会立即刷新到磁盘,因此lsn的值就会和flushed_to_disk_lsn拉开差距。而当log buffer中的日志被刷新到了磁盘,flushed_to_disk_lsn的值就又随之更新。
MTR执行结束后除了将一组日志写入到log buffer外,还需要把执行过程中修改过的页加入到Buffer Pool的flush链表中。
当第一次修改某个已经加载到Buffer Pool中的页面时,就会把这个页面对应的控制块插入到flush链表的头部,之后再修改该页面时,由于它已经在flush链表中,所以就不再次插入了。也就是说,flush链表中的脏页是按照页面第一次修改时间进行排序的,链表前面的脏页第一次修改的时间比较晚,后面的脏页第一次修改的时间比较早。在这个过程中,会在缓冲也对应的控制块中记录两个属性:
多次更新的页面不会重复插入到flush链表中,只会更新newest_modification属性的值。
由于redo日志文件组的容量是有限的,所以我们选择了循环写入redo日志,因此会造成最后写入的redo日志与最开始写入的redo日志追尾的情况。为了避免追尾导致的前面的日志被覆盖而丢失,我们需要判断某些redo日志占用的磁盘空间是否可以被覆盖,也就是说这条redo日志对应的脏页是否已经被刷到了磁盘中。因此InnoDB引入了一个全局变量checkpoint_lsn,用来表示当前系统中可以被覆盖的redo日志总量是多少,这个变量的初始值也是8704。
现在如果当脏页a被刷新到磁盘上,那么这个脏页对应的redo日志就可以被覆盖了,所以可以进行一个增加checkpoint_lsn的操作,我们把这个过程称为执行一次checkpoint。
有些后台线程也会不停的将脏页刷新到磁盘中,但是这和执行一次checkpoint是两回事。一般来讲,刷新脏页和执行checkpoint是在不同线程上执行的,并不是说每次有脏页要刷新就要去执行一次checkpoint。也就是说刷新脏页时会去修改flushed_to_disk_lsn的值,但是不会去修改checkpoint_lsn的值。
执行一次checkpoint可以分为两个步骤:
计算当前系统可以被覆盖的redo日志对应的lsn值最大是多少
将checkpoint_lsn与对应的redo日志文件组偏移量以及这次checkpoint的编号写到日志文件的管理信息(也就是checkpoint1和checkpoint2中)
其中checkpoint_lsn前的redo日志可以覆盖,因为这些日志对应的修改操作已经落盘。而checkpoint_lsn和flushed_to_disk_lsn之间的redo日志不能覆盖,它们只是日志落盘,但是对应的数据页的修改还没刷入磁盘,还指望着系统崩溃后用这部分日志来进行恢复。flushed_to_disk_lsn到lsn之间表示redo日志还在log buffer中没有落盘。
一般脏页都是后台的线程对LRU链表和flush链表进行的,这主要是因为刷脏操作比较慢,不想影响用户线程处理请求。但是如果当前系统修改页面的操作十分频繁,就会导致写redo日志的操作十分频繁,系统lsn值增长过快。如果后台线程的刷脏操作不能将脏页快速刷出,系统将无法即使执行checkpoint,就需要用户线程从flush链表中把那些最早修改的脏页同步刷新到磁盘。这样这些脏页对应的redo日志就没用了,然后就可以去执行checkpoint了。
使用show engine innodb status
命令可以查看当前InnoDB存储引擎中各种lsn值的情况:
前面已经说过了,对于lsn值小于checkpoint_lsn的redo日志而言,它们对应的脏页都已经被刷新到磁盘,所以不需要恢复。而对于lsn不小于checkpoint_lsn的redo日志,它们对应的脏页可能没被刷盘,也可能被刷盘了,并不能确定,因此需要从lsn值为checkpoint_lsn的redo日志开始恢复页面。
在redo日志文件组第一个文件的管理信息中,有两个block都存储了checkpoint_lsn,我们选择其中更大的那个来进行恢复,并根据其对应的checkpoint_offset来对应到redo日志的位置。
确定完起点之后,需要确定恢复的终点。对于redo日志,它们是顺序的写入block中的,也就是写满一个之后才会去写下一个。并且block的log block header中记录了当前block中使用了多少字节的空间,也就是说我们只要恢复到该值不为512的block即可。
确定好恢复的区间之后就可以按顺序遍历redo日志进行恢复了。不过InnoDB还引入了一些机制来加速这个恢复过程: