MySQL存储引擎内部之：`InnoDB`的`Crash Recovery`：`Redo Log`在`崩溃恢复`中的作用。

MySQL InnoDB Crash Recovery: Redo Log 的救赎

各位朋友，大家好！今天我们来聊聊 MySQL InnoDB 存储引擎中一个非常关键的特性：崩溃恢复（Crash Recovery），以及在这个过程中扮演核心角色的 Redo Log。理解 Redo Log 的机制，对于理解 InnoDB 的事务特性、数据一致性至关重要。

1. 为什么需要 Crash Recovery？

首先，让我们思考一个问题：数据库系统在运行过程中，可能面临各种各样的意外情况，比如服务器突然断电、操作系统崩溃、甚至硬件故障。这些意外都可能导致数据库进程非正常终止。如果没有有效的恢复机制，数据库中的数据可能会损坏，或者处于不一致的状态，导致严重的业务问题。

举个简单的例子，假设你正在使用一个电商网站，进行一个购物操作：

1. 你将一件商品加入购物车。
2. 系统从你的账户中扣除相应的金额。

如果在扣款成功之后，服务器突然崩溃了，但商品信息还未来得及写入数据库，那么你的钱就被扣了，但你并没有买到商品，这是一个明显的数据不一致问题。

Crash Recovery 的目的，就是保证在数据库系统经历崩溃之后，能够自动地将数据库恢复到一个一致的状态，尽量减少数据丢失，确保事务的原子性、一致性、隔离性和持久性（ACID）。

2. InnoDB 如何保证 ACID 特性？

InnoDB 存储引擎依赖于一系列机制来保证 ACID 特性，其中最关键的包括：

• Undo Log: 用于回滚未完成的事务，保证原子性。
• Redo Log: 用于在系统崩溃后重做已提交的事务，保证持久性。
• Doublewrite Buffer: 用于防止数据页部分写入，保证数据页的完整性。

今天我们主要聚焦 Redo Log，探讨它在崩溃恢复中的作用。

3. Redo Log 的工作原理

Redo Log 可以理解为一种重做日志，它记录了数据库中每个数据页的物理修改。 当我们执行一个更新操作时，InnoDB 首先将这个更新操作记录到 Redo Log 缓冲区中，然后再将修改应用到实际的数据页上。这种先写日志，后写数据的策略，被称为 Write-Ahead Logging (WAL)。

Redo Log 缓冲区位于内存中，为了保证 Redo Log 的可靠性，InnoDB 会定期将 Redo Log 缓冲区中的内容刷新到磁盘上的 Redo Log 文件中。

3.1 Redo Log 的基本结构

Redo Log 记录的是数据页的物理修改，通常包含以下信息：

• Log Sequence Number (LSN): 一个单调递增的序列号，用于标识 Redo Log 记录的顺序。
• Space ID: 数据页所属的表空间的 ID。
• Page Number: 数据页的页号。
• Offset: 修改在数据页中的偏移量。
• Length: 修改的长度。
• Data: 实际的修改数据。

可以用一个简单的类来表示 Redo Log 记录：

class RedoLogRecord {
public:
    uint64_t lsn;       // Log Sequence Number
    uint32_t space_id;  // 表空间ID
    uint32_t page_no;   // 页号
    uint32_t offset;    // 偏移量
    uint32_t length;    // 长度
    char* data;         // 修改的数据

    RedoLogRecord(uint64_t lsn, uint32_t space_id, uint32_t page_no, uint32_t offset, uint32_t length, char* data)
        : lsn(lsn), space_id(space_id), page_no(page_no), offset(offset), length(length), data(data) {}
};

3.2 Redo Log 的写入过程

1. 修改数据: 当一个事务需要修改数据时，InnoDB 首先获取相应的锁，然后修改数据页的内存副本。
2. 生成 Redo Log: InnoDB 将对数据页的修改信息写入 Redo Log 缓冲区。
3. 更新 LSN: 为 Redo Log 记录分配一个唯一的 LSN，并更新 InnoDB 的全局 LSN。
4. 写入 Redo Log 文件: InnoDB 会定期将 Redo Log 缓冲区中的内容刷新到磁盘上的 Redo Log 文件中。这个过程由后台线程负责，通常采用 Group Commit 的方式，将多个事务的 Redo Log 一起写入，提高效率。
5. 刷新数据页: InnoDB 会在适当的时候，将修改后的数据页刷新到磁盘上。这个过程是异步的，由后台线程负责。

3.3 Redo Log 的刷新策略

InnoDB 提供了多种 Redo Log 刷新策略，由 innodb_flush_log_at_trx_commit 参数控制：

• 0: 每秒刷新一次 Redo Log 缓冲区到磁盘。这种方式性能最高，但如果服务器崩溃，可能会丢失最近一秒钟的事务。
• 1: 每个事务提交时，都将 Redo Log 缓冲区刷新到磁盘。这种方式是最安全的，但性能相对较低。
• 2: 每个事务提交时，将 Redo Log 缓冲区写入操作系统的文件系统缓存，由操作系统决定何时刷新到磁盘。这种方式的性能介于 0 和 1 之间，但如果操作系统崩溃，仍然可能丢失数据。

通常情况下，建议使用 innodb_flush_log_at_trx_commit=1，保证数据的安全性。

4. Crash Recovery 的过程

现在，我们来深入了解 Crash Recovery 的过程，看看 Redo Log 如何发挥作用。

当 MySQL 服务器启动时，InnoDB 首先会检查是否存在未完成的 Redo Log。如果存在，则执行以下步骤：

1. 分析 Redo Log: InnoDB 从 Redo Log 文件的头部开始，顺序读取 Redo Log 记录，分析哪些事务已经提交，哪些事务尚未提交。
2. 重做已提交的事务: 对于已经提交的事务，InnoDB 会根据 Redo Log 记录，将这些事务对数据页的修改重做一遍，确保这些修改已经持久化到磁盘上。
3. 回滚未提交的事务: 对于尚未提交的事务，InnoDB 会根据 Undo Log 记录，将这些事务对数据页的修改回滚，保证事务的原子性。
4. 清理脏页: InnoDB 会清理缓冲池中的脏页，确保数据的一致性。

可以用伪代码来描述 Crash Recovery 的过程：

void crash_recovery() {
    // 1. 分析 Redo Log
    std::vector<RedoLogRecord> redo_records = analyze_redo_log();
    std::set<uint64_t> committed_txns = get_committed_transactions(redo_records);
    std::set<uint64_t> uncommitted_txns = get_uncommitted_transactions(redo_records);

    // 2. 重做已提交的事务
    for (const auto& record : redo_records) {
        if (committed_txns.count(record.lsn)) { //假设LSN和事务ID关联
            redo_page(record.space_id, record.page_no, record.offset, record.length, record.data);
        }
    }

    // 3. 回滚未提交的事务 (假设存在 undo_log_rollback 函数)
    for (const auto& txn_id : uncommitted_txns) {
        undo_log_rollback(txn_id); //使用Undo Log回滚
    }

    // 4. 清理脏页
    cleanup_dirty_pages();
}

void redo_page(uint32_t space_id, uint32_t page_no, uint32_t offset, uint32_t length, char* data) {
    // 1. 读取数据页
    char* page = read_page(space_id, page_no);

    // 2. 应用 Redo Log 中的修改
    memcpy(page + offset, data, length);

    // 3. 将修改后的数据页写回磁盘 (可能需要先写入 doublewrite buffer)
    write_page(space_id, page_no, page);

    // 4. 释放数据页
    free(page);
}

5. LSN (Log Sequence Number) 的重要性

LSN 在 Crash Recovery 中扮演着至关重要的角色。它是一个单调递增的序列号，用于标识 Redo Log 记录的顺序。InnoDB 使用 LSN 来确定 Redo Log 记录的有效性，以及重做和回滚的顺序。

InnoDB 中维护了多个 LSN，包括：

• innodb_lsn: 当前 Redo Log 的 LSN。
• checkpoint_lsn: 最近一次 Checkpoint 的 LSN。
• flushed_lsn: 已经刷新到磁盘上的 Redo Log 的 LSN。

Checkpoint 是一个将脏页刷新到磁盘的过程。InnoDB 会定期执行 Checkpoint，将缓冲池中的脏页刷新到磁盘上，并更新 Checkpoint LSN。Checkpoint LSN 表示所有 LSN 小于等于它的 Redo Log 记录都已经持久化到磁盘上。

在 Crash Recovery 过程中，InnoDB 从 Checkpoint LSN 开始扫描 Redo Log，重做所有 LSN 大于 Checkpoint LSN 的 Redo Log 记录。

6. Doublewrite Buffer 的保护

在将数据页刷新到磁盘的过程中，可能会发生部分写入的情况。例如，在写入过程中，服务器突然崩溃，导致数据页只写入了一部分，造成数据损坏。

为了解决这个问题，InnoDB 引入了 Doublewrite Buffer。Doublewrite Buffer 位于共享表空间中，它是一个 2MB 大小的连续区域。

在将数据页刷新到磁盘之前，InnoDB 首先将数据页写入 Doublewrite Buffer。如果写入过程中发生崩溃，InnoDB 可以从 Doublewrite Buffer 中恢复数据页，避免数据损坏。

Doublewrite Buffer 的工作流程如下：

1. 将要写入磁盘的数据页，先拷贝到 Doublewrite Buffer。
2. 将 Doublewrite Buffer 中的数据页写入磁盘。
3. 将缓冲池中的数据页写入磁盘。

在 Crash Recovery 过程中，如果 InnoDB 检测到数据页可能存在部分写入的情况，它会首先从 Doublewrite Buffer 中恢复数据页，然后再应用 Redo Log 中的修改。

7. 案例分析：一次典型的崩溃恢复场景

假设我们有一个简单的 users 表：

CREATE TABLE users (
    id INT PRIMARY KEY,
    name VARCHAR(255),
    email VARCHAR(255)
);

现在，我们执行以下事务：

START TRANSACTION;
INSERT INTO users (id, name, email) VALUES (1, 'Alice', '[email protected]');
UPDATE users SET email = '[email protected]' WHERE id = 1;
COMMIT;

在事务提交之前，服务器突然崩溃了。

Crash Recovery 的过程如下：

1. 分析 Redo Log: InnoDB 分析 Redo Log，发现事务已经提交。
2. 重做已提交的事务: InnoDB 根据 Redo Log 记录，将 INSERT 和 UPDATE 操作重做一遍，确保 users 表中存在 id=1 的记录，并且 email 字段的值为 [email protected]。
3. 完成恢复: InnoDB 完成 Crash Recovery，数据库恢复到一个一致的状态。

如果没有 Redo Log，INSERT 和 UPDATE 操作可能会丢失，导致数据不一致。

8. Redo Log 的配置参数

以下是一些常用的 Redo Log 配置参数：

参数	描述	默认值
innodb_log_file_size	每个 Redo Log 文件的大小。	48MB
innodb_log_files_in_group	Redo Log 文件的数量。	2
innodb_flush_log_at_trx_commit	控制 Redo Log 缓冲区的刷新策略。	1
innodb_log_buffer_size	Redo Log 缓冲区的大小。	16MB

9. Redo Log 的监控

监控 Redo Log 的状态，可以帮助我们及时发现潜在的问题。

可以使用以下命令查看 Redo Log 的状态：

SHOW GLOBAL STATUS LIKE 'Innodb_os_log_%';

常用的监控指标包括：

• Innodb_os_log_fsyncs: Redo Log 文件刷新的次数。
• Innodb_os_log_pending_fsyncs: 等待刷新的 Redo Log 文件的数量。
• Innodb_os_log_written: 写入 Redo Log 文件的字节数。

如果 Innodb_os_log_pending_fsyncs 的值持续增长，可能表示 Redo Log 刷新速度跟不上写入速度，需要调整 Redo Log 的配置参数。

Redo Log 保证了数据持久性

Redo Log 通过记录数据页的物理修改，保证了即使在系统崩溃的情况下，已经提交的事务也能被恢复，从而保证了数据的持久性。理解 Redo Log 的工作原理，对于理解 InnoDB 的事务特性和数据一致性至关重要。通过合理的配置和监控 Redo Log，可以提高数据库的性能和可靠性。