上回书 MySQL 各种 “Buffer” 之 Doublewrite Buffer 首次提到 Redo Log 的概念，Redo Log 是数据库体系架构中非常重要的一个模块，它能保证数据库的 Crash-safe（崩溃恢复）的能力。而今天要介绍的 Log Buffer 正和 Redo Log 息息相关、密不可分。所以我们就来一起盘它。MySQL 各种 “Buffer” 之 Log Buffer - 图1
MySQL 各种 “Buffer” 之 Log Buffer - 图2
（https://dev.mysql.com/doc/refman/5.7/en/innodb-architecture.html）
参考资料：

  • 丁奇 - 极客时间 APP - 课程《MySQL 实战 45 讲》
  • 58 沈剑 - 架构师之路 - 公众号文章《事务已提交，数据却丢了，赶紧检查下这个配置！！！| 数据库系列》

Redo Log 介绍

Redo Log 是什么

Redo Log（重做日志）是 MySQL 中非常重要的日志模块，（MySQL 官档 https://dev.mysql.com/doc/refman/5.7/en/innodb-redo-log.html 中给出的解释是：重做日志是一种基于磁盘的数据结构，用于在崩溃恢复期间纠正不完整事务写入的数据。在正常操作期间，重做日志对由 SQL 语句或低级 API 调用产生的更改表数据的请求进行编码。在初始化期间和接受连接之前，会自动重播在意外关闭之前未完成更新数据文件的修改），MySQL 里经常说到的 WAL 技术（WAL 的全称是 Write-Ahead Logging），它的关键点就是日志先行（也称为写前日志，实际写数据之前，先把修改的数据记录到日志文之间中。即先写日志，再写磁盘），其实很多数据库软件设计的理念都是日志先行。（但是 Redis 的 AOF（Append Only File）日志正好相反，它是写后日志，“写后” 的意思是 Redis 的先执行命令，把数据写入内存，然后才记录日志），MySQL 中日志先行的这个 “日志” 就是 Redo Log。
Redo Log 是 InnoDB 引擎特有的日志，而 MySQL Server 层也有自己的日志，称为 binlog（不在我们本文的讨论范围，下一章我们就会见到它了，拭目以待吧）。正是因为有了 Redo Log，才保证了 InnoDB 存储引擎的 Crash-safe 能力。
Redo Log 是物理日志，记录的是 “在某个数据页上做了什么修改（做了什么改动）”。一句话概括一下，Redo Log 是为了保证已提交事务的 ACID 特性，同时能够提高数据库性能的技术。

Redo Log 相关参数

SHOW VARIABLES LIKE ‘%innodb_log%’;SHOW VARIABLES LIKE ‘%innodb_flush_log%’;

MySQL 各种 “Buffer” 之 Log Buffer - 图3
从上面可以看出，Redo Log 的相关参数还是很多的，所以我们拿重点的来说，其余参数一般为默认值，感兴趣的同学可移步 MySQL 官档（https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html）进行查阅。

  • 参数：innodb_log_buffer_size

介绍：InnoDB 用于写入磁盘上的日志文件的缓冲区的大小（以字节为单位）。这就是定义我们文章标题的 Log Buffer 大小的参数。随着 32KB 和 64KBinnodb_page_size
值的引入，默认值从 8MB 更改为 16MB。大型日志缓冲区使大型事务能够运行，而无需在事务提交之前将日志写入磁盘。因此，如果您有更新、插入或删除许多行的事务，则增大日志缓冲区可以节省磁盘 I/O。

  • 参数：innodb_log_checksums

介绍：启用或禁用重做日志页面的校验和。innodb_log_checksums=ON 启用 CRC-32C 重做日志页面的校验和算法。当 innodb_log_checksums 被禁用时，重做日志页面校验字段的内容被忽略。重做日志标题页和重做日志检查点页上的校验和永远不会被禁用。默认情况是启用状态，我们按照默认设置就好。

  • 参数：innodb_log_file_size
  • 参数：innodb_log_files_in_group

介绍：innodb_log_file_size 是日志组每个 Redo Log 文件的大小，单位字节。日志文件（innodb_log_file_size
innodb_log_files_in_group）
的组合大小不能超过略小于 512GB 的最大值。innodb_log_files_in_group 是定义日志组文件的数量。从文章开头的架构图可以看出，Log Buffer 也是内存 + 磁盘的结构，这两个参数就是定义 Log Buffer 磁盘结构日志文件组的，同时这两个参数也很重要。
InnoDB 的 Redo Log 是固定大小的，比如截图中的配置为一组 3 个文件，每个文件的大小是 1GB，那么我们 Redo Log 就可以记录 3 × 1G = 3G 的记录。从头开始写，写到末尾就又回到开头循环写，就这样循环覆盖写，如下面这个图所示。
MySQL 各种 “Buffer” 之 Log Buffer - 图4
*write pos 是当前记录的位置，一边写一边后移，写到第 2 号文件末尾后就回到 0 号文件开头。checkpoint 是当前要擦除的位置，也是往后推移并且循环的，擦除记录前要把记录更新到数据文件。write pos 和 checkpoint 之间的 “Free” 部分还空着的部分，可以用来记录新的操作。如果 write pos 追上 checkpoint，表示 Redo Log 满了，这时候不能再执行新的更新，得停下来把 checkpoint 推进一下。
物理数据目录的 Redo Log 长下面这个样子：
MySQL 各种 “Buffer” 之 Log Buffer - 图5

  • 参数：innodb_flush_log_at_trx_commit

介绍：控制提交操作的严格 ACID 合规性与当与提交相关的 I/O 操作重新排列并批量完成时可能实现的更高性能之间的平衡。这个参数非常重要，后面的 Log Buffer 原理主要是关于这个参数的。设置的值不同会产生不同的效果，可设置的值可以是 0、1 或 2。

Log Buffer 工作原理

Redo Log 三层架构

MySQL 各种 “Buffer” 之 Log Buffer - 图6
简单来说一下 Redo Log 的三层结构：

  • 粉色部分：是 InnoDB 一项很重要的内存结构（In-Memory Structure），即我们的 Log Buffer（日志缓冲区），这一层，是 MySQL 应用程序用户态控制。
  • 黄色部分：操作系统文件系统的缓冲区（FS Page Cache），这一层，是操作系统 OS 内核态控制。

  • 绿色部分：就是落盘的物理日志文件。

    Redo Log 最终落盘的步骤

    1、首先，事务提交的时候，会写入 Log Buffer，这里调用的是 MySQL 自己的函数 WriteRedoLog；
    2、接着，只有当 MySQL 发起系统调用写文件 write 时，Log Buffer 里的数据，才会写到 FS Page Cache。注意，MySQL 系统调用完 write 之后，就认为文件已经写完，如果不 flush，什么时候落盘，是操作系统决定的；
    3、最后，由操作系统（当然，MySQL 也可以主动 flush）将 FS Page Cache 里的数据，最终 fsync 到磁盘上；
    一些思考

  • Q-1：操作系统为什么要缓冲数据到 FS Page Cache 里，而不直接刷盘呢？

A-1：这里就是将 “每次写” 优化为 “批量写”，以提高操作系统性能。

  • Q-2：数据库为什么要缓冲数据到 Log Buffer 里，而不是直接 write 呢？

A-2：这也是 “每次写” 优化为 “批量写” 思路的体现，以提高数据库性能。

  • Q-3：Redo Log 三层架构，MySQL 做了一次批量写优化，OS 做了一次批量写优化，确实能极大提升性能，但有什么副作用吗？

A-3：有优点，必有缺点。这个副作用，就是可能丢失数据：
①事务提交时，将 Redo Log 写入 Log Buffer，就会认为事务提交成功；
②如果写入 Log Buffer 的数据，write 入 FS Page Cache 之前，数据库崩溃，就会出现数据丢失；
③如果写入 FS Page Cache 的数据，fsync 入磁盘之前，操作系统奔溃，也可能出现数据丢失；
（如上文所说，应用程序系统调用完 write 之后（不可能每次 write 后都立刻 flush，这样写日志很蠢），就认为写成功了，操作系统何时 fsync，应用程序并不知道，如果操作系统崩溃，数据可能丢失）

MySQL 对上述可能存在问题的折衷方案

参数：innodb_flush_log_at_trx_commit 闪亮登场，能够控制事务提交时，刷 Redo Log 的策略。

  • 目前有三种策略，即对应可设置的值可以是 0、1 或 2。

MySQL 各种 “Buffer” 之 Log Buffer - 图7

  • 策略一：最佳性能（innodb_flush_log_at_trx_commit=0）

处理过程：每隔一秒，才将 Log Buffer 中的数据批量 write 入 FS Page Cache，同时 MySQL 主动 fsync。
缺点：这种策略，如果数据库奔溃，有一秒的数据丢失。

  • 策略二：强一致（innodb_flush_log_at_trx_commit=1）

处理过程：每次事务提交，都将 Log Buffer 中的数据 write 入 FS Page Cache，同时 MySQL 主动 fsync。这种策略，是 InnoDB 的默认配置，为的是保证事务 ACID 特性。
缺点：这种策略，性能较其余两种策略较差。

  • 策略三：折衷（innodb_flush_log_at_trx_commit=2）

处理过程：每次事务提交，都将 Log Buffer 中的数据 write 入 FS Page Cache；每隔一秒，MySQL 主动将 FS Page Cache 中的数据批量 fsync。
缺点：这种策略，如果操作系统奔溃，最多有一秒的数据丢失。（因为 OS 也会 fsync，MySQL 主动 fsync 的周期是一秒，所以最多丢一秒数据。磁盘 IO 次数不确定，因为操作系统的 fsync 频率并不是 MySQL 能控制的）

Redo Log 刷盘策略最佳实践

高并发业务，行业最佳实践，是使用第三种折衷配置（innodb_flush_log_at_trx_commit=2），这是因为：
1、配置为 2 和配置为 0，性能差异并不大，因为将数据从 Log Buffer 拷贝到 FS Page Cache，虽然跨越用户态与内核态，但毕竟只是内存的数据拷贝，速度很快；
2、配置为 2 和配置为 0，安全性差异巨大，操作系统崩溃的概率相比 MySQL 应用程序崩溃的概率，小很多，设置为 2，只要操作系统不奔溃，也绝对不会丢数据。

小结

今天理论的知识不是很多，下面简单做一下总结：
1、Redo Log（重做日志）是 MySQL 中非常重要的日志模块，是为了保证已提交事务的 ACID 特性、保证 InnoDB 存储引擎的 Crash-safe 能力，同时能够提高数据库性能的技术。它是循环覆盖写的物理日志。
2、Redo Log 是一种顺序写，它有三层架构：①Log Buffer；②FS Page Cache；③Redo Log Files；
3、为了满足不用业务对于吞吐量与一致性的需求，MySQL 事务提交时刷 Redo Log 有三种策略：

  • innodb_flush_log_at_trx_commit=0，每秒 write 一次 FS Page Cache，同时 fsync 刷磁盘，性能好；
  • innodb_flush_log_at_trx_commit=1，每次都 write 入 FS Page Cache，同时 fsync 刷磁盘，一致性好；
  • innodb_flush_log_at_trx_commit=2，每次都 write 入 FS Page Cache，每秒 fsync 刷磁盘，折衷；

4、高并发业务，行业内的最佳实践，是：innodb_flush_log_at_trx_commit=2。
今天主要讲解了 Redo Log 和 MySQL InnoDB Log Buffer 的工作原理，通过流程图的方式来说明 Redo Log 三种刷盘策略的工作流程，偏理论的知识，内容比较少也很好理解，大家理解记忆即可，这个知识点非常重要，面试被问到的几率是 99.9%，所以大家一定要掌握该知识点。MySQL 各种 “Buffer” 之 Log Buffer - 图8