注意：根据命名可以看出，这个redo文件并不只有一个，而是以组的形式存在，当0写满就写入1中，1写满就写入2，如果写到最后一个文件，就重新转到0去写，也就是把0的文件覆盖掉。这也就设计了上面的只是checkpoint，什么样的redo日志可以被覆盖。（先说结论，buffer log中的脏页产生的redo 日志，并且这个脏页已经被刷入磁盘，也就意味着此redo 日志已经没有用了，就可以被覆盖了）

三、redo日志文件格式

注意上一篇文章介绍的是redo日志的格式和log buffer的格式。现在介绍的磁盘中的redo日志文件格式。

log buffer与磁盘交互的最小单位——block

log buffer本质就是一片连续的内存空间，被划分成了若干个512字节大小的block。将log buffer 中的redo日志刷新到磁盘本质就是把block的镜像写入日志文件中。

文件格式

由两个部分组成：

~前2048个字节（前4个block）用来存储一些管理信息的。

~从第2048字节往后是用来存储log buffer中的block镜像的。

~注意：上面说过的覆盖循环就是从每个日志文件的第2048字节开始算。

四、Log Sequeue Number（了解）

简称lsn，日志序列号。为什么要介绍他呢，他又有什么作用？

首先我们要知道虽然redo日志小，但是一个语句可以产生很多mtr，而mtr会产生很多redo日志，所以redo日志的数量不断快速递增，那我们怎么确定把redo日志写在log buffer的什么位置呢，lsn被设计出来了。

lsn初始值8704（设计就是这么设计的），当log buffer中一条日志也没写入的时候lsn的值就是8704。

lsn随着日志插入增加，lsn的增长量是的计算（需要计算block的log block header和log block trailer）：

如果某个 mtr 产⽣的⼀组 redo ⽇志占⽤的存储空间⽐较⼩，也就是待插⼊的block剩余空闲空间能容纳这个 mtr 提交的⽇志时， lsn 增⻓的量就是该 mtr ⽣成的 redo

⽇志占⽤的字节数，就像这样

我们假设上图中 mtr_1 产⽣的 redo ⽇志量为200字节，那么 lsn 就要在 8716 的基础上增加 200 ，变为 8916 。

如果某个 mtr 产⽣的⼀组 redo ⽇志占⽤的存储空间⽐较⼤，也就是待插⼊的block剩余空闲空间不⾜以容纳这个 mtr 提交的⽇志时， lsn 增⻓的量就是该 mtr ⽣成

的 redo ⽇志占⽤的字节数加上额外占⽤的 log block header 和 log block trailer 的字节数，就像这样：

五、崩溃恢复

讲了这么多不知道大家发现没有，redo在服务器没有挂的时候完全就是累赘，浪费了很多时间和少量的空间。但是万一数据库挂了，那redo日志就是很厉害了，重启之后就可以根据redo日志将页面恢复到崩溃前的状态。那恢复的过程都发生了什么呢？

1、确定恢复的起点

上面没有介绍怎么确定哪些redo日志可以被覆盖，log buffer刷盘机制有一个就是脏页刷入之前，先将redo日志刷入磁盘，这些就没有必要刷入了，但是伴随着别的机制所以磁盘中可能存在脏页还没有刷入的redo日志，这些是有用的，不能被覆盖，而恢复就是从这个点之后进行顺序恢复，注意这个点之后的redo日志对应的脏页可能被刷入磁盘了，这点我们不能确定，不确定就全刷，mysql也有机制判断是否被刷入。

2、确定恢复的重点

终点我们想当然的觉得终点很容易确定，就是最后的block，但是计算机怎么确定是最后的block呢？

普通block的 log block header 部分有⼀个称之为 LOG_BLOCK_HDR_DATA_LEN 的属性

对于被填满的block这个属性都是512，不是512那就是扫描到最后的一个block。

3、开始恢复

checkpoint_lsn就是上面说的那个点，这之前的脏页都被刷入到磁盘了，索引恢复后面的redo日志，这些日志放在block中。

顺序写入的，也要顺序恢复。

用什么方法恢复？

如果按照顺序依次恢复页没问题，但是mysql还是使用方法加快恢复：

哈希表

之后就可以遍历哈希表，因为对同⼀个⻚⾯进⾏修改的 redo ⽇志都放在了⼀个槽⾥，所以可以⼀次性将⼀个⻚⾯修复好（避免了很多读取⻚⾯的随机IO），这样可以加快恢复速度。另外需要注意⼀点的是，同⼀个⻚⾯的 redo ⽇志是按照⽣成时间顺序进⾏排序的，所以恢复的时候也是按照这个顺序进⾏恢复，如果不按照⽣成时间顺序进⾏排序的话，那么可能出现错误。⽐如原先的修改操作是先插⼊⼀条记录，再删除该条记录，如果恢复时不按照这个顺序来，就可能变成先删除⼀条记录，再插⼊⼀条记录，这显然是错误的。

同时跳过已经刷新到磁盘的页面

我们前边说过， checkpoint_lsn 之前的 redo ⽇志对应的脏⻚确定都已经刷到磁盘了，但是 checkpoint_lsn 之后的 redo ⽇志我们不能确定是否已经刷到磁盘，主要是因为在最近做的⼀次 checkpoint 后，可能后台线程⼜不断的从 LRU 链表和 flush 链表中将⼀些脏⻚刷出 Buffer Pool 。这些在 checkpoint_lsn 之后的 redo ⽇志，如果它们对应的脏⻚在奔溃发⽣时已经刷新到磁盘，那在恢复时也就没有必要根据 redo ⽇志的内容修改该⻚⾯了。

那在恢复时怎么知道某个 redo ⽇志对应的脏⻚是否在奔溃发⽣时已经刷新到磁盘了呢？这还得从⻚⾯的结构说起，我们前边说过每个⻚⾯都有⼀个称之为 File Header 的部分，在 File Header ⾥有⼀个称之为 FIL_PAGE_LSN 的属性，该属性记载了最近⼀次修改⻚⾯时对应的 lsn 值（其实就是⻚⾯控制块中的 newest_modification 值）。如果在做了某次 checkpoint 之后有脏⻚被刷新到磁盘中，那么该⻚对应的 FIL_PAGE_LSN 代表的 lsn 值肯定⼤于 checkpoint_lsn 的值，凡是符合这种情况的⻚⾯就不需要重复执⾏lsn值⼩于 FIL_PAGE_LSN 的redo⽇志了，所以更进⼀步提升了奔溃恢复的速度。这就是上面说的mysql判断脏页刷入磁盘的机制。

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/繁依Fanyi0/article/detail/575889