房地产开发公司网站源代码 墨绿色风格,受欢迎的集团网站建设,淘宝代运营是什么意思,建站公司兴田德润在哪里1.redo日志文件 1.1.redo日志刷盘时机 我们前边说 mtr 运行过程中产生的一组 redo 日志在 mtr 结束时会被复制到 log buffer 中#xff0c;可是这些日志总在内存里呆着也不是个办法#xff0c;在一些情况下它们会被刷新到磁盘里#xff0c;比如#xff1a; (1). log buffer…1.redo日志文件 1.1.redo日志刷盘时机 我们前边说 mtr 运行过程中产生的一组 redo 日志在 mtr 结束时会被复制到 log buffer 中可是这些日志总在内存里呆着也不是个办法在一些情况下它们会被刷新到磁盘里比如 (1). log buffer 空间不足时 log buffer 的大小是有限的通过系统变量 innodb_log_buffer_size 指定如果不停的往这个有限大小的 log buffer 里塞入日志很快它就会被填满。设计 InnoDB 的大叔认为如果当前写入 log buffer 的 redo 日志量已经占满了 log buffer 总容量的大约一半左右就需要把这些日志刷新到磁盘上。 (2). 事务提交时 我们前边说过之所以使用 redo 日志主要是因为它占用的空间少还是顺序写在事务提交时可以不把修改过的 Buffer Pool 页面刷新到磁盘但是为了保证持久性必须要把修改这些页面对应的 redo 日志刷新到磁盘。 (3). 后台线程不停的刷刷刷 后台有一个线程大约每秒都会刷新一次 log buffer 中的 redo 日志到磁盘。 (4). 正常关闭服务器时 (5). 做所谓的 checkpoint 时我们现在没介绍过 checkpoint 的概念稍后会仔细唠叨稍安勿躁 (6). 其他的一些情况…
1.2.redo日志文件组 MySQL 的数据目录使用 SHOW VARIABLES LIKE datadir 查看下默认有两个名为 ib_logfile0 和 ib_logfile1 的文件 log buffer 中的日志默认情况下就是刷新到这两个磁盘文件中。如果我们对默认的 redo 日志文件不满意可以通过下边几个启动参数来调节 (1). innodb_log_group_home_dir 该参数指定了 redo 日志文件所在的目录默认值就是当前的数据目录。 (2). innodb_log_file_size 该参数指定了每个 redo 日志文件的大小在 MySQL 5.7.21 这个版本中的默认值为 48MB 。 (3). innodb_log_files_in_group 该参数指定 redo 日志文件的个数默认值为2最大值为100。
从上边的描述中可以看到磁盘上的 redo 日志文件不只一个而是以一个 日志文件组 的形式出现的。这些文件以 ib_logfile[数字] 数字 可以是 0 、 1 、 2 ...的形式进行命名。在将 redo 日志写入 日志文件组 时是从 ib_logfile0 开始写如果 ib_logfile0 写满了就接着 ib_logfile1 写同理 ib_logfile1 写满了就去写 ib_logfile2 依此类推。如果写到最后一个文件该咋办那就重新转到 ib_logfile0 继续写所以整个过程如下图所示 总共的 redo 日志文件大小其实就是 innodb_log_file_size × innodb_log_files_in_group 。
小贴士如果采用循环使用的方式向redo日志文件组里写数据的话那岂不是要追尾也就是后写入的 redo日志覆盖掉前边写的redo日志当然可能了所以设计InnoDB的大叔提出了checkpoint的概念稍后我们重点唠叨
1.3. redo日志文件格式 我们前边说过 log buffer 本质上是一片连续的内存空间被划分成了若干个 512 字节大小的 block 。将log buffer中的redo日志刷新到磁盘的本质就是把block的镜像写入日志文件中所以 redo 日志文件其实也是由若干个 512 字节大小的block组成。
redo 日志文件组中的每个文件大小都一样格式也一样都是由两部分组成 (1). 前2048个字节也就是前4个block是用来存储一些管理信息的。 (2). 从第2048字节往后是用来存储 log buffer 中的block镜像的。
所以我们前边所说的 循环 使用redo日志文件其实是从每个日志文件的第2048个字节开始算画个示意图就是这样 普通block的格式我们在唠叨 log buffer 的时候都说过了就是 log block header 、 log block body 、 log block trialer 这三个部分就不重复介绍了。这里需要介绍一下每个 redo 日志文件前2048个字节也就是前4个特殊block的格式都是干嘛的废话少说先看图 从图中可以看出来这4个block分别是 (1). log file header 描述该 redo 日志文件的一些整体属性看一下它的结构 各个属性的具体释义如下
属性名长度描述LOG_HEADER_FORMAT4redo 日志的版本在 MySQL5.7.21 中该值永远为1LOG_HEADER_PAD14做字节填充用的没什么实际意义忽略LOG_HEADER_START_LSN8标记本 redo 日志文件开始的LSN值也就是文件偏移量为2048字节初对应的LSN值关于什么是LSN我们稍后再看哈看不懂的先忽略。LOG_HEADER_CREATOR32一个字符串标记本 redo 日志文件的创建者是谁。正常运行时该值为 MySQL 的版本号比如 “MySQL 5.7.21” 使用mysqlbackup 命令创建的 redo 日志文件的该值为 “ibbackup” 和创建时间。LOG_BLOCK_CHECKSUM4本block的校验值所有block都有我们不关心
(2). checkpoint1 记录关于 checkpoint 的一些属性看一下它的结构 各个属性的具体释义如下
属性名长度描述LOG_CHECKPOINT_NO8服务器做 checkpoint 的编号每做一次 checkpoint 该值就加1。LOG_CHECKPOINT_LSN8服务器做 checkpoint 结束时对应的 LSN 值系统奔溃恢复时将从该值开始。LOG_CHECKPOINT_OFFSET8上个属性中的 LSN 值在 redo 日志文件组中的偏移量LOG_CHECKPOINT_LOG_BUF_SIZE8服务器在做 checkpoint 操作时对应的 log buffer 的大小LOG_BLOCK_CHECKSUM4本block的校验值所有block都有我们不关心
(3). 第三个block未使用忽略 (4). checkpoint2 结构和 checkpoint1 一样。
2.Log Sequeue Number 自系统开始运行就不断的在修改页面也就意味着会不断的生成 redo 日志。 redo 日志的量在不断的递增就像人的年龄一样自打出生起就不断递增永远不可能缩减了。设计 InnoDB 的大叔为记录已经写入的 redo 日志量设计了一个称之为 Log Sequeue Number 的全局变量翻译过来就是 日志序列号 简称 lsn 。不过不像人一出生的年龄是 0 岁设计 InnoDB 的大叔规定初始的 lsn 值为 8704 也就是一条 redo 日志也没写入时lsn 的值为 8704 。
我们知道在向 log buffer 中写入 redo 日志时不是一条一条写入的而是以一个 mtr 生成的一组 redo 日志为单位进行写入的。而且实际上是把日志内容写在了 log block body 处。但是在统计 lsn 的增长量时是按照实际写入的日志量加上占用的 log block header 和 log block trailer 来计算的。我们来看一个例子 (1). 系统第一次启动后初始化 log buffer 时 buf_free 就是标记下一条 redo 日志应该写入到 log buffer 的位置的变量就会指向第一个 block 的偏移量为12字节 log block header 的大小的地方那么 lsn值也会跟着增加12 (2). 如果某个 mtr 产生的一组 redo 日志占用的存储空间比较小也就是待插入的block剩余空闲空间能容纳这个 mtr 提交的日志时 lsn 增长的量就是该 mtr 生成的 redo 日志占用的字节数就像这样 我们假设上图中 mtr_1 产生的 redo 日志量为200字节那么 lsn 就要在 8716 的基础上增加 200 变为 8916 。
(3). 如果某个 mtr 产生的一组 redo 日志占用的存储空间比较大也就是待插入的block剩余空闲空间不足以容纳这个 mtr 提交的日志时 lsn 增长的量就是该 mtr 生成的 redo 日志占用的字节数加上额外占用的 log block header 和 log block trailer 的字节数就像这样 我们假设上图中 mtr_2 产生的 redo 日志量为1000字节为了将 mtr_2 产生的 redo 日志写入 log buffer 我们不得不额外多分配两个block所以 lsn 的值需要在 8916 的基础上增加 1000 12×2 4 × 2 1032 。
从上边的描述中可以看出来每一组由mtr生成的redo日志都有一个唯一的LSN值与其对应LSN值越小说明 redo日志产生的越早。
3.flushed_to_disk_lsn redo 日志是首先写到 log buffer 中之后才会被刷新到磁盘上的 redo 日志文件。所以设计 InnoDB 的大叔提出了一个称之为buf_next_to_write 的全局变量标记当前 log buffer 中已经有哪些日志被刷新到磁盘中了。画个图表示就是这样 我们前边说 lsn 是表示当前系统中写入的 redo 日志量这包括了写到 log buffer 而没有刷新到磁盘的日志相应的设计 InnoDB 的大叔提出了一个表示刷新到磁盘中的 redo 日志量的全局变量称之为 flushed_to_disk_lsn 。系统第一次启动时该变量的值和初始的 lsn 值是相同的都是 8704 。随着系统的运行 redo 日志被不断写入 log buffer 但是并不会立即刷新到磁盘 lsn 的值就和 flushed_to_disk_lsn 的值拉开了差距。我们演示一下 (1). 系统第一次启动后向 log buffer 中写入了 mtr_1 、 mtr_2 、 mtr_3 这三个 mtr 产生的 redo 日志假设这三个 mtr 开始和结束时对应的lsn值分别是 a. mtr_1 8716 8916 b. mtr_2 8916 9948 c. mtr_3 9948 10000 此时的 lsn 已经增长到了10000但是由于没有刷新操作所以此时 flushed_to_disk_lsn 的值仍为 8704 如图 (2). 随后进行将 log buffer 中的block刷新到 redo 日志文件的操作假设将 mtr_1 和 mtr_2 的日志刷新到磁盘那么 flushed_to_disk_lsn 就应该增长 mtr_1 和 mtr_2 写入的日志量所以 flushed_to_disk_lsn 的值增长到了 9948 如图 综上所述当有新的 redo 日志写入到 log buffer 时首先 lsn 的值会增长但 flushed_to_disk_lsn 不变随后随着不断有 log buffer 中的日志被刷新到磁盘上 flushed_to_disk_lsn 的值也跟着增长。如果两者的值相同时说明log buffer中的所有redo日志都已经刷新到磁盘中了。
小贴士 应用程序向磁盘写入文件时其实是先写到操作系统的缓冲区中去如果某个写入操作要等到操作系统确认已经写到磁盘时才返回那需要调用一下操作系统提供的fsync函数。其实只有当系统执行了fsync函数后flushed_to_disk_lsn的值才会跟着增长当仅仅把log buffer中的日志写入到操作系统缓冲区却没有显式的刷新到磁盘时另外的一个称之为write_lsn的值跟着增长。不过为了大家理解上的方便我们在讲述时把flushed_to_disk_lsn和write_lsn的概念混淆了起来。
4.lsn值和redo日志文件偏移量的对应关系 因为 lsn 的值是代表系统写入的 redo 日志量的一个总和一个 mtr 中产生多少日志 lsn 的值就增加多少当然有时候要加上 log block header 和 log block trailer 的大小这样 mtr 产生的日志写到磁盘中时很容易计算某一个 lsn 值在 redo 日志文件组中的偏移量如图 初始时的 LSN 值是 8704 对应文件偏移量 2048 之后每个 mtr 向磁盘中写入多少字节日志 lsn 的值就增长多少。
5.flush链表中的LSN 我们知道一个 mtr 代表一次对底层页面的原子访问在访问过程中可能会产生一组不可分割的 redo 日志在 mtr 结束时会把这一组 redo 日志写入到 log buffer 中。除此之外在 mtr 结束时还有一件非常重要的事情要做就是把在mtr执行过程中可能修改过的页面加入到Buffer Pool的flush链表。为了防止大家早已忘记 flush链表 是个啥我们再看一下图 当第一次修改某个缓存在 Buffer Pool 中的页面时就会把这个页面对应的控制块插入到 flush链表 的头部之后再修改该页面时由于它已经在 flush 链表中了就不再次插入了。也就是说flush链表中的脏页是按照页面的第一次修改时间从大到小进行排序的。在这个过程中会在缓存页对应的控制块中记录两个关于页面何时修改的属性 (1). oldest_modification 如果某个页面被加载到 Buffer Pool 后进行第一次修改那么就将修改该页面的 mtr 开始时对应的 lsn 值写入这个属性。 (2). newest_modification 每修改一次页面都会将修改该页面的 mtr 结束时对应的 lsn 值写入这个属性。 也就是说该属性表示页面最近一次修改后对应的系统 lsn 值。
我们接着上边唠叨 flushed_to_disk_lsn 的例子看一下 (1). 假设 mtr_1 执行过程中修改了 页a 那么在 mtr_1 执行结束时就会将 页a 对应的控制块加入到 flush链表 的头部。并且将 mtr_1 开始时对应的 lsn 也就是 8716 写入 页a 对应的控制块的 oldest_modification 属性中把 mtr_1 结束时对应的 lsn 也就是8916写入 页a 对应的控制块的 newest_modification 属性中。画个图表示一下为了让图片美观一些我们把 oldest_modification 缩写成了 o_m 把 newest_modification 缩写成了 n_m (2). 接着假设 mtr_2 执行过程中又修改了 页b 和 页c 两个页面那么在 mtr_2 执行结束时就会将 页b 和 页c对应的控制块都加入到 flush链表 的头部。并且将 mtr_2 开始时对应的 lsn 也就是8916写入 页b 和 页c 对应的控制块的 oldest_modification 属性中把 mtr_2 结束时对应的 lsn 也就是9948写入 页b 和 页c 对应的控制块的 newest_modification 属性中。画个图表示一下 从图中可以看出来每次新插入到 flush链表 中的节点都是被放在了头部也就是说 flush链表 中前边的脏页修改的时间比较晚后边的脏页修改时间比较早。
(3). 接着假设 mtr_3 执行过程中修改了 页b 和 页d 不过 页b 之前已经被修改过了所以它对应的控制块已经被插入到了 flush 链表所以在 mtr_3 执行结束时只需要将 页d 对应的控制块都加入到 flush链表 的头部即可。所以需要将 mtr_3 开始时对应的 lsn 也就是9948写入 页d 对应的控制块的 oldest_modification 属性中把 mtr_3 结束时对应的 lsn 也就是10000写入 页d 对应的控制块的 newest_modification 属性中。另外由于 页b 在 mtr_3 执行过程中又发生了一次修改所以需要更新 页b 对应的控制块中 newest_modification 的值为10000。画个图表示一下 总结一下上边说的就是flush链表中的脏页按照修改发生的时间顺序进行排序也就是按照 oldest_modification代表的LSN值进行排序被多次更新的页面不会重复插入到flush链表中但是会更新 newest_modification属性的值。
6.checkpoint 有一个很不幸的事实就是我们的 redo 日志文件组容量是有限的我们不得不选择循环使用 redo 日志文件组中的文件但是这会造成最后写的 redo 日志与最开始写的 redo 日志 追尾 这时应该想到redo日志只是为了系统奔溃后恢复脏页用的如果对应的脏页已经刷新到了磁盘也就是说即使现在系统奔溃那么在重启后也用不着使用redo日志恢复该页面了所以该redo日志也就没有存在的必要了那么它占用的磁盘空间就可以被后续的 redo日志所重用。也就是说判断某些redo日志占用的磁盘空间是否可以覆盖的依据就是它对应的脏页是否已经刷新到磁盘里。我们看一下前边一直唠叨的那个例子 如图虽然 mtr_1 和 mtr_2 生成的 redo 日志都已经被写到了磁盘上但是它们修改的脏页仍然留在 Buffer Pool 中所以它们生成的 redo 日志在磁盘上的空间是不可以被覆盖的。之后随着系统的运行如果 页a 被刷新到了磁盘那么它对应的控制块就会从 flush链表 中移除就像这样子 这样 mtr_1 生成的 redo 日志就没有用了它们占用的磁盘空间就可以被覆盖掉了。设计 InnoDB 的大叔提出了一个全局变量 checkpoint_lsn 来代表当前系统中可以被覆盖的 redo 日志总量是多少这个变量初始值也是 8704 。
比方说现在 页a 被刷新到了磁盘 mtr_1 生成的 redo 日志就可以被覆盖了所以我们可以进行一个增加 checkpoint_lsn 的操作我们把这个过程称之为做一次 checkpoint 。做一次 checkpoint 其实可以分为两个步骤 (1). 计算一下当前系统中可以被覆盖的 redo 日志对应的 lsn 值最大是多少。 redo 日志可以被覆盖意味着它对应的脏页被刷到了磁盘只要我们计算出当前系统中被最早修改的脏页对应的 oldest_modification 值那凡是在系统lsn值小于该节点的oldest_modification值时产生的redo日志都是可以被覆盖掉的我们就把该脏页的 oldest_modification 赋值给 checkpoint_lsn 。比方说当前系统中 页a 已经被刷新到磁盘那么 flush链表 的尾节点就是 页c 该节点就是当前系统中最早修改的脏页了它的 oldest_modification 值为8916我们就把8916赋值给 checkpoint_lsn 也就是说在redo日志对应的lsn值小于8916时就可以被覆盖掉。 (2). 将 checkpoint_lsn 和对应的 redo 日志文件组偏移量以及此次 checkpint 的编号写到日志文件的管理信息就是 checkpoint1 或者checkpoint2 中。
设计 InnoDB 的大叔维护了一个目前系统做了多少次 checkpoint 的变量 checkpoint_no 每做一次 checkpoint 该变量的值就加1。我们前边说过计算一个 lsn 值对应的 redo 日志文件组偏移量是很容易的所以可以计算得到该 checkpoint_lsn 在 redo 日志文件组中对应的偏移量 checkpoint_offset 然后把这三个值都写到 redo 日志文件组的管理信息中。
我们说过每一个 redo 日志文件都有 2048 个字节的管理信息但是上述关于checkpoint的信息只会被写到日志文件组的第一个日志文件的管理信息中。不过我们是存储到 checkpoint1 中还是 checkpoint2 中呢设计 InnoDB 的大叔规定当 checkpoint_no 的值是偶数时就写到 checkpoint1 中是奇数时就写到 checkpoint2 中。
记录完 checkpoint 的信息之后 redo 日志文件组中各个 lsn 值的关系就像这样 7.批量从flush链表中刷出脏页 我们在介绍 Buffer Pool 的时候说过一般情况下都是后台的线程在对 LRU链表 和 flush链表 进行刷脏操作这主要因为刷脏操作比较慢不想影响用户线程处理请求。但是如果当前系统修改页面的操作十分频繁这样就导致写日志操作十分频繁系统 lsn 值增长过快。如果后台的刷脏操作不能将脏页刷出那么系统无法及时做 checkpoint 可能就需要用户线程同步的从 flush链表 中把那些最早修改的脏页 oldest_modification 最小的脏页刷新到磁盘这样这些脏页对应的 redo 日志就没用了然后就可以去做 checkpoint 了。
8.查看系统中的各种LSN值 我们可以使用 SHOW ENGINE INNODB STATUS 命令查看当前 InnoDB 存储引擎中的各种 LSN 值的情况比如
mysql SHOW ENGINE INNODB STATUS\G
(...省略前边的许多状态)
LOG
---
Log sequence number 124476971
Log flushed up to 124099769
Pages flushed up to 124052503
Last checkpoint at 124052494
0 pending log flushes, 0 pending chkp writes
24 log i/os done, 2.00 log i/os/second
----------------------
(...省略后边的许多状态)其中 (1). Log sequence number 代表系统中的 lsn 值也就是当前系统已经写入的 redo 日志量包括写入 log buffer 中的日志。 (2). Log flushed up to 代表 flushed_to_disk_lsn 的值也就是当前系统已经写入磁盘的 redo 日志量。 (3). Pages flushed up to 代表 flush链表 中被最早修改的那个页面对应的 oldest_modification 属性值。 (4). Last checkpoint at 当前系统的 checkpoint_lsn 值。
9.innodb_flush_log_at_trx_commit的用法 我们前边说为了保证事务的 持久性 用户线程在事务提交时需要将该事务执行过程中产生的所有 redo 日志都刷新到磁盘上。这一条要求太狠了会很明显的降低数据库性能。如果有的同学对事务的 持久性 要求不是那么强烈的话可以选择修改一个称为innodb_flush_log_at_trx_commit 的系统变量的值该变量有3个可选的值 (1). 0 当该系统变量值为0时表示在事务提交时不立即向磁盘中同步 redo 日志这个任务是交给后台线程做的。 这样很明显会加快请求处理速度但是如果事务提交后服务器挂了后台线程没有及时将 redo 日志刷新到磁盘那么该事务对页面的修改会丢失。 (2).1 当该系统变量值为1时表示在事务提交时需要将 redo 日志同步到磁盘可以保证事务的 持久性 。 1 也是 innodb_flush_log_at_trx_commit 的默认值。 (3). 2 当该系统变量值为2时表示在事务提交时需要将 redo 日志写到操作系统的缓冲区中但并不需要保证将日志真正的刷新到磁盘。
这种情况下如果数据库挂了操作系统没挂的话事务的 持久性 还是可以保证的但是操作系统也挂了的话那就不能保证 持久性 了。
10.崩溃恢复 在服务器不挂的情况下 redo 日志简直就是个大累赘不仅没用反而让性能变得更差。但是万一我说万一啊万一数据库挂了那 redo 日志可是个宝了我们就可以在重启时根据 redo 日志中的记录就可以将页面恢复到系统奔溃前的状态。我们接下来大致看一下恢复过程是个啥样。
10.1.确定恢复的起点 我们前边说过 checkpoint_lsn 之前的 redo 日志都可以被覆盖也就是说这些 redo 日志对应的脏页都已经被刷新到磁盘中了既然它们已经被刷盘我们就没必要恢复它们了。对于 checkpoint_lsn 之后的 redo 日志它们对应的脏页可能没被刷盘也可能被刷盘了我们不能确定所以需要从 checkpoint_lsn 开始读取 redo 日志来恢复页面。
当然 redo 日志文件组的第一个文件的管理信息中有两个block都存储了 checkpoint_lsn 的信息我们当然是要选取最近发生的那次checkpoint的信息。衡量 checkpoint 发生时间早晚的信息就是所谓的 checkpoint_no 我们只要把 checkpoint1 和 checkpoint2 这两个block中的 checkpoint_no 值读出来比一下大小哪个的 checkpoint_no 值更大说明哪个block存储的就是最近的一次 checkpoint 信息。这样我们就能拿到最近发生的 checkpoint 对应的 checkpoint_lsn 值以及它在 redo 日志文件组中的偏移量 checkpoint_offset 。
10.2.确定恢复的终点 redo 日志恢复的起点确定了那终点是哪个呢这个还得从block的结构说起。我们说在写 redo 日志的时候都是顺序写的写满了一个block之后会再往下一个block中写 普通block的 log block header 部分有一个称之为 LOG_BLOCK_HDR_DATA_LEN 的属性该属性值记录了当前block里使用了多少字节的空间。对于被填满的block来说该值永远为 512 。如果该属性的值不为 512 那么就是它了它就是此次奔溃恢复中需要扫描的最后一个block。
10.3.怎么恢复 确定了需要扫描哪些 redo 日志进行奔溃恢复之后接下来就是怎么进行恢复了。假设现在的 redo 日志文件中有 5条 redo 日志如图 由于 redo 0 在 checkpoint_lsn 后边恢复时可以不管它。我们现在可以按照 redo 日志的顺序依次扫描checkpoint_lsn 之后的各条redo日志按照日志中记载的内容将对应的页面恢复出来。这样没什么问题不过设计 InnoDB 的大叔还是想了一些办法加快这个恢复的过程 (1). 使用哈希表 根据 redo 日志的 space ID 和 page number 属性计算出散列值把 space ID 和 page number 相同的 redo日志放到哈希表的同一个槽里如果有多个 space ID 和 page number 都相同的 redo 日志那么它们之间使用链表连接起来按照生成的先后顺序链接起来的如图所示 之后就可以遍历哈希表因为对同一个页面进行修改的 redo 日志都放在了一个槽里所以可以一次性将一个页面修复好避免了很多读取页面的随机IO这样可以加快恢复速度。另外需要注意一点的是同一个页面的 redo 日志是按照生成时间顺序进行排序的所以恢复的时候也是按照这个顺序进行恢复如果不按照生成时间顺序进行排序的话那么可能出现错误。比如原先的修改操作是先插入一条记录再删除该条记录如果恢复时不按照这个顺序来就可能变成先删除一条记录再插入一条记录这显然是错误的。
(2). 跳过已经刷新到磁盘的页面 我们前边说过 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日志了所以更进一步提升了奔溃恢复的速度。
10.4.遗漏的问题LOG_BLOCK_HDR_NO是如何计算的 我们前边说过对于实际存储 redo 日志的普通的 log block 来说在 log block header 处有一个称之为 LOG_BLOCK_HDR_NO 的属性忘记了的话回头再看看哈我们说这个属性代表一个唯一的标号。这个属性是初次使用该block时分配的跟当时的系统 lsn 值有关。使用下边的公式计算该block的 LOG_BLOCK_HDR_NO 值((lsn / 512) 0x3FFFFFFFUL) 1。
这个公式里的 0x3FFFFFFFUL 可能让大家有点困惑其实它的二进制表示可能更亲切一点 从图中可以看出 0x3FFFFFFFUL 对应的二进制数的前2位为0后30位的值都为 1 。我们刚开始学计算机的时候就学过一个二进制位与0做与运算 的结果肯定是0一个二进制位与1做与运算 的结果就是原值。让一个数和 0x3FFFFFFFUL 做与运算的意思就是要将该值的前2个比特位的值置为0这样该值就肯定小于或等于0x3FFFFFFFUL 了。这也就说明了不论lsn多大 ((lsn / 512) 0x3FFFFFFFUL) 的值肯定在0~0x3FFFFFFFUL 之间再加1的话肯定在 1~0x40000000UL 之间。而 0x40000000UL 这个值大家应该很熟悉这个值就代表着 1GB 。也就是说系统最多能产生不重复的 LOG_BLOCK_HDR_NO 值只有 1GB 个。设计InnoDB的大叔规定 redo 日志文件组中包含的所有文件大小总和不得超过512GB一个block大小是512字节也就是说redo日志文件组中包含的block块最多为1GB个所以有1GB个不重复的编号值也就够用了。
另外 LOG_BLOCK_HDR_NO 值的第一个比特位比较特殊称之为 flush bit 如果该值为1代表着本block是在某次将 log buffer 中的block刷新到磁盘的操作中的第一个被刷入的block。
