详解重做日志（Redo Log)

枯河垂钓

已于 2025-04-05 20:46:37 修改

阅读量564

点赞数 16

分类专栏： # MySQL日志文件文章标签： mysql dba

于 2025-04-05 11:04:51 首次发布

本文链接：https://blog.youkuaiyun.com/weixin_57024726/article/details/147009006

版权

MySQL日志文件专栏收录该内容

15 篇文章

订阅专栏

一、认识重做日志（Redo Log）

1. 为什么需要重做日志？

数据持久性保障
重做日志是 MySQL InnoDB 存储引擎中实现数据持久性的核心组件。当事务对数据进行修改时，这些修改会先记录到重做日志中。如果系统在事务完成前发生崩溃，重做日志可以确保未完成的事务能够被正确恢复，从而保证数据的完整性。

崩溃恢复
重做日志记录了对数据页的物理修改操作（如某一页的某一部分被更新）。在系统崩溃后，InnoDB 会通过重做日志将数据恢复到崩溃前的最新状态。这种机制避免了直接从磁盘读取大量数据进行恢复的高开销。

提高写入性能
重做日志采用顺序写入的方式，将随机的磁盘写操作转换为顺序写操作。这种方式显著减少了磁盘的随机 I/O 操作，提高了写入效率，尤其是在高并发写场景下表现尤为明显。

2. 重做日志记录的是什么？

记录内容
重做日志记录的是数据页的物理修改操作，而不是逻辑操作。例如，当某一行数据被更新时，重做日志会记录该数据页的页号、偏移量以及修改后的内容。

与 Binlog 的区别

Binlog：记录的是逻辑操作（如 SQL 语句的执行），用于主从复制和数据恢复。
Redo Log：记录的是物理操作（如数据页的修改），用于崩溃恢复。

3. 重做日志的工作机制

顺序写入与组提交
重做日志采用顺序写入的方式，所有事务的重做日志会按照顺序写入日志文件中。此外，InnoDB 使用组提交（Group Commit）机制，将多个事务的重做日志批量写入磁盘，从而减少磁盘 I/O 次数，提高性能。

预写式日志（Write-Ahead Logging, WAL）
在数据页被修改之前，相关的重做日志必须先写入磁盘。这种机制确保了即使系统崩溃，数据页的修改可以通过重做日志恢复。

日志缓冲区与刷盘
重做日志首先写入内存中的日志缓冲区（Log Buffer），然后定期或在特定条件下刷写到磁盘。刷盘的频率可以通过 innodb_flush_log_at_trx_commit 参数控制：

0：每秒刷写一次。
1（默认）：每次事务提交时刷写。
2：每次事务提交时标记缓冲区，但实际刷写由后台线程完成。

二、重做日志与相关技术的关系

1. 重做日志与 Binlog

两阶段提交（Two-Phase Commit）
为了保证事务的逻辑操作（Binlog）和物理操作（Redo Log）的一致性，MySQL 使用了两阶段提交机制：

准备阶段：事务的 Redo Log 被标记为 prepare 状态并持久化到磁盘。
提交阶段：事务的 Binlog 被写入磁盘后，Redo Log 被标记为 commit 状态。

意义
通过两阶段提交，确保了 Binlog 和 Redo Log 的一致性。即使系统崩溃，也可以通过 Redo Log 和 Binlog 恢复事务的状态，保证数据的完整性和一致性。

2. 重做日志与脏页

脏页的定义
脏页是指在缓冲池中被修改但尚未写回磁盘的数据页。

重做日志的作用
当脏页被刷新到磁盘时，重做日志确保了即使在刷新过程中发生崩溃，数据页的修改可以通过重做日志恢复。这种机制避免了“半页问题”（即数据页只写入了一部分导致数据损坏）。

三、查看 MySQL 的重做日志配置

1. 查看重做日志保存路径和文件

SHOW GLOBAL VARIABLES LIKE 'innodb_log_group_home_dir';
SHOW GLOBAL VARIABLES LIKE 'innodb_log_file%';

innodb_log_group_home_dir：重做日志文件的存储路径。
innodb_log_file_size：每个重做日志文件的大小。
innodb_log_files_in_group：重做日志文件的数量。

2. 查看重做日志的运行状态

SHOW ENGINE INNODB STATUS\G

在输出中可以查看重做日志的当前状态，包括日志序列号（LSN）、日志缓冲区的使用情况等。

四、两阶段提交（Two-Phase Commit, 2PC）

1. 两阶段提交的概述

两阶段提交是一种分布式事务提交协议，用于确保分布式系统中多个节点的操作一致性。它分为两个阶段：准备阶段（Prepare Phase） 和 提交阶段（Commit Phase）。

2. 准备阶段（Prepare Phase）

操作：
1. 将事务的 XID（内部 XA 事务的 ID） 写入到 Redo Log。
2. 将 Redo Log 对应的事务状态设置为 prepare，并将 Redo Log 持久化到磁盘（受 innodb_flush_log_at_trx_commit 参数控制）。
目的：
- 确保事务的物理修改（如数据页的更新）已经持久化，即使在后续过程中发生崩溃，也可以通过 Redo Log 进行恢复。
- 为后续的提交阶段提供事务的准备状态。

3. 提交阶段（Commit Phase）

操作：
1. 将 XID 写入到 Binlog。
2. 将 Binlog 持久化到磁盘中（受 sync_binlog 参数控制）。
3. 调用存储引擎的提交接口，将 Redo Log 的事务状态设置为 commit。此时，该状态不需要立即持久化到磁盘，只需写入操作系统的 page cache 即可。
目的：
- 确保事务的逻辑操作（如 SQL 语句的执行）已经记录到 Binlog 中，以便在主从复制或数据恢复时使用。
- 完成事务的最终提交。

4. 两阶段提交的意义

保证一致性：
- 通过两阶段提交，确保 Redo Log 和 Binlog 的内容一致，避免因日志不一致导致的数据问题。
- 在分布式系统中，确保所有节点的操作要么全部成功，要么全部失败。
提高可靠性：
- 即使在系统崩溃的情况下，也可以通过 Redo Log 和 Binlog 恢复事务的状态，保证数据的持久性和一致性。
- Binlog 用于主从复制，Redo Log 用于本地恢复，两者协同工作确保数据的完整性。

五、重做日志与两阶段提交的关系

协同工作：
- 在两阶段提交的 准备阶段，Redo Log 被用来记录事务的物理修改，确保事务的物理状态可以恢复。
- 在两阶段提交的 提交阶段，Binlog 被用来记录事务的逻辑操作，确保事务的逻辑状态可以恢复。
- 两者的协同确保了事务在物理和逻辑层面的一致性。
恢复机制：
- 在系统崩溃后，通过 Redo Log 恢复事务的物理状态。
- 通过 Binlog 恢复事务的逻辑状态，确保主从复制的一致性。
一致性保证：
- 两阶段提交通过 Redo Log 和 Binlog 的协同工作，确保事务的物理和逻辑操作都完成，从而保证事务的一致性。

六、重做日志在崩溃恢复中的作用

1. 崩溃恢复流程

检查点（Checkpoint）
InnoDB 定期将缓冲池中的脏页刷新到磁盘，并记录检查点信息。检查点之前的日志可以被丢弃，因为对应的数据页已经持久化。
前滚恢复（Roll-Forward Recovery）
在系统崩溃后，InnoDB 会从重做日志中读取未完成的事务，并重新应用这些修改，将数据恢复到崩溃前的最新状态。