Fork me on GitHub

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

原文链接:提问式复习:图文回顾 redo log 相关知识

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

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-恢复

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日志 了,

最后,祝大家国庆节快乐!

posted @ 2021-10-01 17:47  不送花的程序猿  阅读(498)  评论(0编辑  收藏  举报