MySQL InnoDB 存储引擎 Redo Log（重做日志）详解

1 Redo Log 的作用与重要性

Redo Log 是 InnoDB 存储引擎中用于实现事务持久性和崩溃恢复的关键组件。它的主要功能是记录对数据库页（page）所做的物理修改，确保即使在系统崩溃的情况下，已经提交的事务也不会丢失，并且可以被正确地恢复。这使得 InnoDB 具备了 **crash-safe** 的能力，即在发生意外重启时，之前提交的数据不会丢失。

2 Redo Log 的工作机制

2.1 写入过程

- 当一个事务对数据进行插入、更新或删除操作时，这些更改首先会被记录到内存中的缓冲池（Buffer Pool），同时生成相应的 redo log 记录。
- 这些 redo log 记录会先存放在内存中的 redo log buffer 中。InnoDB 使用了一个循环缓冲区来存储这些日志条目。
- 根据配置参数 `innodb_flush_log_at_trx_commit` 的值，决定何时将 redo log buffer 中的内容刷新到磁盘上的 redo log 文件：
- 设置为0：表示每次事务提交时都只是把 redo log 留在 redo log buffer 中，不立即写入磁盘。这种方式虽然性能较好，但在数据库宕机时可能会丢失数据。
- 设置为1（默认值）：表示每次事务提交时都将 redo log 直接持久化到磁盘，保证了数据的安全性，但效率稍微低一些。
- 设置为2：表示每次事务提交时都只是把 redo log 写到操作系统的缓存（page cache）里，操作系统再根据自己的调度策略将这些日志写入磁盘。这种方式比设置为1更高效，但如果操作系统也宕机，则可能丢失未同步的日志。

2.2 刷盘机制

- InnoDB 有一个后台线程每隔一秒就会尝试将 redo log buffer 中的日志调用操作系统函数 `write` 写入文件系统的 page cache，并通过 `fsync` 持久化到磁盘。
- 此外，当 redo log buffer 占满或者达到一定阈值时，也会触发一次强制刷盘操作，以避免日志溢出导致新的写入无法进行。

2.3 循环使用

- Redo log 文件是以循环方式使用的，这意味着它们会在写满后重新从头开始覆盖旧的日志条目。每个 redo log 文件都有两个重要的位置指针：
- write pos：当前记录的位置，随着新日志的产生而不断向前推进，一旦到达最后一个文件末尾就回到第一个文件开头继续写入。
- checkpoint：当前要擦除的位置，同样也是往后推移并且循环的。它标志着上一次检查点之后的所有更改都已经安全地保存到了数据文件中。因此，在正常情况下，write pos 和 checkpoint 之间的部分就是空闲可写的区域；如果 write pos 追上了 checkpoint，则说明 redo log 已经写满，需要暂停新的写入直到 checkpoint 推进。

2.4 Checkpoints（检查点）

- Checkpoint 是 InnoDB 用来标识哪些页面已经被成功写回磁盘的一个标记。每当有新的数据页被修改并写入磁盘时，对应的 checkpoint 就会向前移动。
- 在系统崩溃恢复期间，InnoDB 可以利用 checkpoint 来确定哪些日志条目是必须应用的，从而快速恢复到最近的一致状态。

3 Redo Log 的配置参数

- `innodb_log_buffer_size`：设置 redo log buffer 的大小，默认为16MB。较大的缓冲区可以减少磁盘I/O次数，但同时也增加了内存占用和潜在的数据丢失风险（仅限于非持久化模式下）。
- `innodb_log_group_home_dir`：指定 redo log 文件存放的位置，默认为 "./"，即 InnoDB 数据目录所在路径。
- `innodb_log_files_in_group`：定义了属于同一组的 redo log 文件数量，默认为2个，最大支持100个。
- `innodb_log_file_size`：单个 redo log 文件的最大尺寸，默认为48MB。需要注意的是，整个 redo log 系列文件的总容量不能超过512GB（即 `innodb_log_files_in_group * innodb_log_file_size <= 512GB`）。
- `innodb_flush_log_at_trx_commit`：控制 redo log 刷新到磁盘的行为，如前所述，取值范围为0到2，默认为1。