MySQL学习总结：提问式图文回顾 redo log 相关知识

以你之姓@ 2022-09-14 08:43 25阅读 0赞

## 1、如何提升 redo日志 的写性能？ ##

*  为了保证 redo日志 不丢失，会在磁盘中开辟一块空间将日志保存起来。但是这样会有一个问题，磁盘的读写性能非常的差。
 *  所以 redo日志 和数据页一样，系统都是会分配一块连续的内存，来提升读写性能；数据页对应的是 buffer pool，而 redo日志 对应的是 log buffer。

> buffer pool可以利用「innodb\_buffer\_pool\_size」指定总大小，利用「innodb\_buffer\_pool\_instances」指定实例数，但是必须size大于等于1G才生效。
> 
> log buffer 可利用「innodb\_log\_buffer\_size」指定 log buffer 的大小；一片连续的内存空间会被划分为N个512字节大小的block。
> 
> log file 可以利用「innodb\_log\_file\_size」指定每个 log file 的大小，利用「innodb\_log\_files\_in\_group」指定一共多少个log file。

## 2、redo日志 何时写入log buffer？ ##

*  对底层页面（可能是多个页面）进行一次原子性访问，等于一个MTR，即 Mini Transaction。一个 MTR对应一组 redo日志 。一个事务对应多个语句，一个语句对应多个个MTR，一个MTR对应一组redo日志，即多个 redo日志 。
 *  在MTR结束后，会将一组 redo日志 写入到log buffer中。

详情可看下图：  
![redo-lsn-offset][]

## 3、log buffer 中的 redo日志 何时刷盘？ ##

*  当 log buffer 已经被写入约一半左右，下次再写入 redo日志 时，需将 log buffer 的 redo日志 刷到磁盘文件中。
 *  当事务结束时，需先将 log buffer 中，被修改的缓存页对应的 redo日志 刷回磁盘中。
 *  后台线程刷，大概每隔一秒刷一次 log buffer 中的 redo日志 到磁盘中。
 *  执行checkpoint。
 *  正常关闭服务器。

## 4、我们都知道每次写入 redo日志 ，都是以组为单位，那么我们怎么知道哪些是一组？ ##

*  在该组中的最后一条 redo日志 后边加上一条特殊类型的 redo日志 ，该类型名称为「MLOG\_MULTI\_REC\_END」，type字段对应的十进制数字为31，该类型的 redo日志 结构很简单，只有一个type字段。

## 5、如何知道下一次redo日志改写到log buffer的哪个位置？ ##

*  buf\_free全局变量，指向log buffer中下个写入的位置。

## 6、如何知道下次从log buffer的哪个位置开始刷入磁盘？ ##

*  buf\_next\_to\_write全局变量，指向log buffer中下个刷回磁盘的位置。

## 7、如何定位 log buffer 中的 redo日志 对应哪些被修改的数据页；在被修改的数据页中，如何定位到对应的是哪些 redo日志 ？ ##

*  修改的缓存页找到对应的 redo日志
    
     *  lsn
        
         *  首先，出场一个变量，叫lsn，全称：log sequence number，日志序列号。它记录的是，redo日志 的总字节数，初始值为8704。当系统启动，初始化log buffer 时，lsn 值为 8704+12（一个log block header）=8716
         *  接着，log buffer 是由多个block组成的(可以理解为buffer pull的缓存页)，block由三部分组成，log block header（12个字节）、log block body、log block trailer（4个字节）。
         *  当第一个 redo日志 组，如「mt\_1」准备被写入，并且一个block能容纳，此时lsn为 8704+12（一个log block header）=8716，假设「mt\_1」一共100字节，那么「mt\_1」写入后，lsn为8716+100=8816
         *  当第二个 redo日志 组，如「mt\_2」准备被写入，并且需要跨block才能容纳，如跨一个（即包含一个log block header和一个log block trailer），开始写入前lsn：8816，假设「mt\_2」一共1000个字节，那么「mt\_2」写入后，lsn为8816+12（一个log header）+4（一个log tail）+1000=9832
     *  flush和lsn
        
         *  当 MTR 结束时，会将被修改过的数据页对应的数据块放入 flush链表 的表头中，并且给两个参数赋值，分别是 old\_modification 和 new\_modification：old\_m 赋值是 MTR 开始前的 lsn 值，而 new\_m 赋值是 MTR 结束时的 lsn 值。
         *  如果一个 MTR 修改的数据页对应的控制块本来就在 flush链表 中，则不调整数据页对应的数据块的位置，只是修改 new\_modification 的值，old\_modification还 是保持第一次进入 flush链表 时 lsn 的值。
         *  就是说，在 flush链表 中，数据块是根据第一次修改的时间进行倒序排列的。
     *  通过上面，那么我们可以根据flush链表中，数据块的 old\_modification 和 new\_modification 找到对应的一组 redo日志 ，因为通过 lsn 可以定位到对应 redo日志 在磁盘文件中的偏移量（这个下面会讲解到）。
 *  redo日志 找到对应的缓存页面
    
     *  redo日志 的通用结构是：type-spaceId ID-page Number-data，即我们可以根据 redo日志 的 space ID 和 page Number 即可找到对应的缓存页。
     *  顺带一提：在 InnoDB 中，有一个哈希表，key为表空间号+页号，value为缓存页地址。这样我们可以通过 space ID 和 page Number 快速定位到对应的缓存页。

## 8、我们知道可以利用 lsn 知道有多少字节数的 redo日志 写入到 log buffer 中，那么我们能有变量对应的知道有多少字节数的 redo日志 被刷入磁盘中吗？ ##

*  flushed\_to\_disk\_lsn 全局变量，表示刷到磁盘的日志量。

## 9、lsn 和 log file 的偏移量怎么对得上么？ ##

*  lsn 初始值是 8704，随着 redo日志 的不断写入，lsn 不断增大。而 innodb 中，是利用 block 这个结构来存储 redo日志 （不管是 log buffer 还是 log file），而 block 包含三部分，上面已经提到。当 redo日志 不断写入，不断占用 block 的空间，那么 lsn 会增加对应的字节数，当然了，除了body、也算 header 和 trailer。
 *  log file 是由日志组组成，日志组最大设置100个文件数，每个日志文件也是由多个512字节的block镜像组成，日志组第一个日志文件前4个block镜像用于存储重要信息、如checkpoint等、即前2048个字节不用于存储 redo日志 ，即从2048个字节开始计算 redo日志 的存放量。
 *  log file 的 log file header 中有一个「LOG\_HEADER\_START\_LSN」属性，标记本 redo日志 文件偏移量2048字节处对应的lsn值。

详情可看下图：  
![redo-lsn-offset][redo-lsn-offset 1]

## 10、log buffer 中的 redo日志 真的会在事务结束时立马刷回到磁盘中吗？ ##

*  默认是的，这里有一个参数控制：「innodb\_flushing\_log\_at\_trx\_commit」，默认值是1
    
     *  0:事务提交，不会立马刷到磁盘中，依赖后台线程刷入，即如果此时MySQL或系统挂掉重启，无法恢复脏页
     *  1:事务提交，会立马将log buffer的 redo日志 刷回磁盘中
     *  2:事务提交，会立马将log buffer的 redo日志 刷到操作系统的缓存中，而不是刷到磁盘中；如果此时MySQL挂掉了，重启后不会影响恢复脏页，而如果是系统挂掉，就无力回天了。

## 11、log file 都是循环使用，即可以覆盖，那么怎么判断是否可以覆盖？ ##

*  log file 中可被覆盖，那么首要条件就是 redo日志 对应的脏页已经被刷到磁盘中。
 *  innodb 有个全局变量：checkpoint\_lsn，它记录的是可被覆盖的 redo日志量。初始值就是lsn的初始值，8704。
    
     *  什么是 checkpoint？
        
         *  当有脏页被刷到磁盘时，首先在flus链表中拿到最旧的缓存页，即需要拿到链表尾部的控制块，然后拿到 old\_modification 的值，然后将这个值赋值给 checkpoint\_lsn，因为只要是小于 flush 链表中最旧的控制块的 old\_modification 的 lsn，就代表可以被覆盖，毕竟对应的脏页已经被刷到磁盘中了。
         *  接着，将根据当前的 checkpoint\_lsn 获取对应日志文件组的偏移量，记录为 checkpoint\_offset，checkpoint\_no 也需要加1，最后将三个信息记录在日志文件组的 checkpoint1 或 checkpoint2（checkpoint\_no为奇数存1，否则存2）。
         *  上面两步称为执行一次checkpoint。
 *  我们只需要从日志文件组中的 checkpoint1 和 checkpoint2 拿到信息，然后对比 checkpoint\_no 看哪个是最新的，接着拿到checkpoint\_lsn，那么 lsn 小于 checkpoint\_lsn 的日志都可以被覆盖。

## 12、系统崩溃重启，如何利用 redo日志 进行恢复？ ##

*  redo日志 进行崩溃恢复主要是利用上面提到的 checkpoint\_lsn，因为 checkpoint\_lsn 表示可以覆盖的日志量，则表示 checkpoint\_lsn 之前的 redo日志 对应的脏页都已经被刷回到磁盘中。
 *  首先从 redo 日志组中拿到 checkpoint1 和 checkpoint2，接着判断谁的 checkpoint\_no 大，大的就是最新的一次 checkpoint 执行。
 *  接着拿到对应的 checkpoint\_offset，那么 checkpoint\_offset 后的 redo日志 都需要扫描一遍，然后根据 redo日志 的内容，对数据页进行恢复。

## 13、恢复是扫描一个 redo日志 ，就进行一次恢复吗？ ##

*  问题：
    
     *  因为根据 redo日志 恢复数据页的变更，是直接更新磁盘中的数据页；扫描一个 redo日志 ，就进行一次恢复，如果存在多个 redo日志 记录同一个数据页的变更，并且不是连续的，那么会导致多次随机IO，性能会非常的差。
 *  解决：
    
     *  所以会有一个哈希表，key为 space ID + page Number，value 为数据页地址。扫描 redo日志 时，会将同一个 space ID + page Number 的 redo日志 都放在同一个槽下。
     *  接着遍历哈希表，执行每一个 space ID + page Number 对应所有的 redo日志 。
 *  好处：
    
     *  避免了多次的随机IO，提升恢复的速度。
     *  按顺序根据 redo日志 进行恢复，避免出现恢复的顺序问题。

详情可看下图：  
![redo-恢复][redo-]

## 14、恢复时，如何知道什么时候结束? ##

*  首先，我们知道，在日志组里，有多个block镜像，然后 redo日志 刷盘，是按顺序填入每个block的，只有前一个block填满了，才接着填下一个
 *  接着，每个 block 的大小都是 512 个字节，包括 log block header、log block body 和 log block trailer。在block的页面结构中，log block header 头部有一个「LOG\_BLOCK\_HDR\_DATA\_LEN」的属性，该属性值记录了当前block里使用了多少字节的空间。对于被填满的block来说，该值永远为512。
 *  最后，所以只管往后面一直扫，直到 log block header 中 「LOG\_BLOCK\_HDR\_DATA\_LEN」属性不是512的 block，那么就是恢复的终点了。

## 15、如何兼容脏页已经已经刷回磁盘，但是 redo日志 没有刷回磁盘的场景？ ##

*  场景复现：
    
     *  当我们提交事务时，会根据参数「innodb\_flush\_at\_trx\_commit」来做下一步操作，如果是0或者2，那么此时的日志并没有刷回到磁盘中，而是留在log buffer中或操作系统缓存中。
     *  接着，如果有后台线程将 LRU 链表或 flush 链表的某些脏页刷回磁盘中，刷回后；但是此时对应的 redo日志 还停留在上面提到的两个地方，如果服务器宕机，那么对应的 redo日志 就会丢失了。
     *  因为刷 LRU 链表、flush 链表和刷 redo日志 的后台线程，往往都是不同的线程，无法知道对应的 redo日志 是否已经刷回去。
 *  兼容：
    
     *  每个数据页都有一个称之为 File Header 的部分，在 File Header 里有一个称之为 FIL\_PAGE\_LSN 的属性，该属性记载了最近一次修改页面时对应的 lsn 值（其实就是页面控制块中的 newest\_modification 值）。
     *  如果在做了某次 checkpoint 之后有脏页被刷新到磁盘中，那么该页对应的 FIL\_PAGE\_LSN 代表的 lsn 值肯定大于 checkpoint\_lsn 的值，凡是符合这种情况的页面就不需要重复执行 lsn 值小于 FIL\_PAGE\_LSN 的 redo日志 了，

最后，祝大家国庆节快乐！

[redo-lsn-offset]: /images/20220828/8b62c25da90740cd9d9cae8e96c5d4c8.png
[redo-lsn-offset 1]: /images/20220828/baf577e12bcb44a88600b7de2aab0653.png
[redo-]: /images/20220828/4874afa6664d45a4a4fc69925839acb7.png