MySQL 日志：Redo、Bin 与 Undo Log

于 2024-11-13 07:00:00 发布
阅读量1.2k 收藏 16
点赞数 28
分类专栏： MySQL 文章标签： mysql 数据库
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/tatasix/article/details/143711742
版权

文章目录

第一章 引言

1.1 MySQL日志系统的概述

在数据库系统中，数据的一致性和持久性是最核心的要求。在【深入理解MySQL事务】中，我们讲解了MySQL的事务实现，提到了Redo Log，Undo Log，Bin Log。MySQL 作为流行的关系型数据库，采用多种日志机制来保障数据库在高并发和分布式环境下的可靠性和恢复能力。这些日志机制主要包括：

  • Redo Log：负责数据库的持久性和崩溃恢复。
  • Bin Log：负责主从复制和时间点恢复（Point-In-Time Recovery）。
  • Undo Log：负责事务回滚和多版本并发控制（MVCC）。

在数据库操作中，每种日志记录不同的数据信息、以不同的方式写入、在不同场景中使用，并对系统性能产生不同影响。接下来的内容中，我们将详细分析这些日志的原理、存储方式、写入策略和使用场景，并深入对比三者的差异。

1.2 Redo Log、Bin Log 和 Undo Log 的基本作用

1.2.1 Redo Log

Redo Log 主要用于记录物理变更，即每次数据页发生变更时所产生的变更记录。它的核心目标是持久性保障，通过记录变更操作，可以在数据库异常崩溃后进行恢复，将数据库状态恢复到崩溃前的最新状态。

  • 示例：假设一个事务更新了10条记录，由于操作繁多，未能及时将数据同步到磁盘。当数据库发生故障时，通过 Redo Log，系统可以根据记录的操作重现变更，从而避免数据丢失。
1.2.2 Bin Log

Bin Log 用于记录每个事务的逻辑变更，即 SQL 语句的执行记录。Bin Log 的主要目的是在主从复制中同步数据、在系统恢复中实现增量恢复。

  • 示例：在主从数据库的架构下，主库将所有 SQL 变更操作记录到 Bin Log 中，从库再从主库读取这些 Bin Log 并执行相同的操作，达到数据同步的效果。
1.2.3 Undo Log

Undo Log 主要记录事务中的历史版本，即在事务执行过程中修改前的数据版本。Undo Log 的核心作用是实现事务回滚和多版本并发控制（MVCC）。

  • 示例：在事务中更新某条记录失败，通过 Undo Log 可以回滚到原始数据状态，从而保证数据库的一致性。

1.3 三种日志的对比

特性Redo LogBin LogUndo Log
记录内容物理变更数据SQL 逻辑变更事务历史版本
作用数据持久性、崩溃恢复主从同步、增量恢复事务回滚、MVCC
写入方式按页顺序写入，循环写入按事务顺序写入，追加写入按事务开始写入，回滚段管理
应用场景高并发事务写入、快速恢复主从复制、数据同步高并发读写隔离
删除方式基于 Checkpoint 定期清理手动删除或根据保留天数自动清理事务完成后自动清理历史版本

第二章 MySQL 更新流程概述

2.1 一次更新请求的流程概述

在 MySQL 中，当客户端发起一条更新请求（例如 UPDATE 语句）时，该请求将经历以下主要步骤：

  1. 接收请求：MySQL 接收到请求并传递给 InnoDB 存储引擎。
  2. 解析和优化：SQL 被解析和优化，生成执行计划。
  3. 执行事务：InnoDB 引擎开始执行数据修改操作，并同时写入三种日志（Redo Log、Bin Log 和 Undo Log）。
  4. 提交事务：在二阶段提交（2PC）下协调 Bin Log 和 Redo Log 的一致性，最终完成事务提交。

我们通过一个流程图来说明三种日志在更新流程中的位置和作用：
接收请求
SQL解析和优化
执行计划
更新数据
写入 Undo Log
写入 Redo Log
写入 Bin Log
事务提交
提交完成

2.2 三种日志在更新流程中的角色与作用

为了更清晰地展示每种日志的作用，我们以 UPDATE 操作为例，分析 Redo Log、Bin Log 和 Undo Log 各自的执行步骤与记录内容。

2.2.1 Redo Log 在更新流程中的角色

Redo Log 在整个更新流程中起到持久化保障和性能优化的作用：

  • 写入时机：当数据页发生变更时，将更改内容记录到 Redo Log Buffer 中，以保证事务持久性。
  • 提交时写入磁盘：Redo Log 会在事务提交前写入磁盘，以实现 Write-Ahead Logging（WAL），确保所有日志信息在实际数据写入之前持久化。
  • 崩溃恢复：数据库崩溃时，Redo Log 可以根据记录的变更重做，恢复最新的数据库状态。
2.2.2 Bin Log 在更新流程中的角色

Bin Log 记录的是 SQL 逻辑操作，用于数据库的主从复制和Point-In-Time 恢复：

  • 写入时机：当事务执行时，将 SQL 操作以事件的形式写入 Bin Log。
  • 二阶段提交：在二阶段提交协议（2PC）下，Bin Log 和 Redo Log 的顺序确保事务在主从节点间的一致性。
  • 主从复制：在主从复制场景中，主库将 Bin Log 发送到从库，从库依次重放操作以保持数据同步。
2.2.3 Undo Log 在更新流程中的角色

Undo Log 是在事务开始时写入的历史版本，用于回滚操作和并发控制：

  • 写入时机：事务开始时，记录每个数据页的原始状态，以便需要时回滚。
  • MVCC 支持：在多版本并发控制（MVCC）场景中，Undo Log 为读操作提供了历史版本支持，保证读写隔离。
  • 回滚保障：在事务失败或执行 ROLLBACK 时，通过 Undo Log 可以回滚到事务开始前的状态，确保数据一致性。

2.3 二阶段提交（2PC）：协调 Redo Log 与 Bin Log 的一致性

在事务的提交过程中，为了保证持久性和一致性，MySQL 采用了二阶段提交（2PC）机制，将 Redo Log 与 Bin Log 进行协调。这一过程如下：

  1. 第一阶段：预提交

    • 将所有数据变更记录到 Redo Log Buffer 中。
    • Redo Log Buffer 持久化到磁盘中，但未真正标记提交。

  2. 第二阶段：正式提交

    • 将 Bin Log 写入磁盘并标记提交。
    • 更新 Redo Log 的提交标记。

这两个阶段保证了 Bin Log 和 Redo Log 的一致性，以避免在崩溃恢复或主从复制时数据不一致的情况。

Client MySQL RedoLog BinLog UndoLog 开始事务 写入历史版本 写入变更数据 写入SQL操作 提交标记 返回事务成功 Client MySQL RedoLog BinLog UndoLog

2.4 三种日志在更新流程中的协作关系

Redo Log、Bin Log 和 Undo Log 在事务更新过程中协同工作，保障数据库的持久性、一致性和隔离性：

  • 持久性：Redo Log 的 Write-Ahead Logging 确保在数据落盘前记录日志。
  • 数据一致性：通过 Bin Log 实现主从同步和数据恢复。
  • 并发隔离：通过 Undo Log 实现 MVCC，确保不同事务间的隔离。

第三章 Redo Log

3.1 Redo Log 的作用与设计目标

Redo Log 是 InnoDB 存储引擎中保证数据持久性和提升写入性能的核心机制。Redo Log 记录的是物理数据变更，例如数据页的修改。其主要作用和设计目标包括：

  1. 保障持久性：通过预写日志（Write-Ahead Logging, WAL），确保数据库崩溃后能够恢复事务的最新状态，避免数据丢失。
  2. 提升写性能：通过顺序写入的方式，将随机 IO 转化为顺序 IO，提升磁盘写入性能。
  3. 查询性能优化：在多用户并发环境中，通过 Redo Log 的变更记录，查询可以快速定位到最新数据，减少直接读写数据页的频率，从而降低磁盘的读写压力。

3.2 Write-Ahead Logging (WAL) 机制

Write-Ahead Logging (WAL) 是 Redo Log 的关键机制。WAL 的基本思想是先记录日志再更新数据，即在每次写入数据页之前，先将变更记录写入 Redo Log，从而确保即使系统崩溃，数据也能从日志中恢复。这一机制的具体实现步骤如下：

  1. 将变更记录写入 Redo Log Buffer：在事务执行过程中，所有变更首先写入 Redo Log Buffer 而不是直接修改磁盘上的数据页。
  2. 将 Redo Log Buffer 刷入磁盘：在事务提交时，将 Redo Log Buffer 持久化到磁盘。
  3. 实际数据页更新：在合适的时机，通过 Checkpoint 将内存中的数据页刷入磁盘。

示例：假设我们执行了一条 UPDATE 语句更新了某行数据。事务会先将变更写入 Redo Log Buffer，而不是直接写入磁盘上的数据页。当事务提交时，Redo Log 会同步到磁盘，确保数据变更被记录下来。这种机制即使在系统崩溃时也能通过 Redo Log 进行数据恢复。

3.3 Redo Log 的结构和关键组成部分

Redo Log 由多个日志文件构成，其核心组件包括：

  1. LSN（Log Sequence Number）：每条日志记录的唯一标识，用于追踪变更顺序和数据一致性。
  2. Checkpoint：日志的同步点，记录数据页和日志的同步进度。
  3. 循环日志文件：Redo Log 使用固定大小的循环日志文件，按顺序写入，记录最新的数据页变更。

以下是 Redo Log 的结构图：
循环写入
事务开始
Redo Log Buffer
Redo Log 文件
磁盘
Checkpoint 管理

3.4 Redo Log 的写入方式与时机

Redo Log 的写入过程包括写入 Redo Log Buffer 和刷入磁盘两个步骤，具体的写入方式和时机如下：

  1. 写入 Redo Log Buffer：在数据变更时，变更记录首先写入 Redo Log Buffer，而不是直接修改磁盘的数据页。

  2. 刷入磁盘的策略：

    • 根据 innodb_flush_log_at_trx_commit 参数的不同值决定写入策略：
      • 0：不在事务提交时刷盘，仅定期将 Redo Log Buffer 刷入磁盘，效率最高但持久性最差。
      • 1：在每次事务提交时立即刷盘，确保事务持久性，适合高一致性要求的场景。
      • 2：在事务提交时仅将日志写入操作系统缓存，不立即刷盘，适合中等一致性和性能要求的场景。

  3. 顺序写入与随机 IO 转化：Redo Log 使用顺序写入方式，将每次数据变更记录按序追加到日志文件中。这种方式减少了磁盘的随机 IO 操作，提升了写入效率。

3.5 Change Buffer 机制

Change Buffer 是 InnoDB 中一种优化非唯一索引更新的机制，通过延迟写入减少磁盘写操作，加速事务提交。Change Buffer 的工作原理如下：

  1. 延迟非唯一索引的更新：当事务修改非唯一索引时，InnoDB 不会立即将数据页写入磁盘，而是将更改暂存到 Change Buffer 中。
  2. 批量写入：在之后的数据访问或合适的时机，InnoDB 将 Change Buffer 中的记录应用到磁盘上的数据页，从而减少了单次写操作。
  3. 提高写入效率：Change Buffer 和 Redo Log 协同工作，通过延迟非唯一索引写入，加速事务提交，尤其在大量更新的情况下效果显著。

Change Buffer 示例：如果某事务批量更新了非唯一索引的数据页，InnoDB 会将这些更新缓存在 Change Buffer 中，避免了立即更新磁盘。稍后在空闲时或数据页被访问时，InnoDB 将批量更新磁盘上的索引，提高了写入效率。

3.6 Redo Log 的适用场景与存储管理

Redo Log 的适用场景主要包括：

  1. 高并发事务写入：通过顺序写入和 WAL 机制，减少磁盘 IO，适合高并发的事务写入。
  2. 崩溃恢复：在系统崩溃或故障时，Redo Log 允许数据库从最近的 Checkpoint 恢复，减少数据丢失。
  3. 数据一致性保障：通过协调 Redo Log 和 Bin Log，实现主从同步中的数据一致性。

在存储管理方面，Redo Log 采用固定大小的循环日志文件，并通过 Checkpoint 定期清理已应用的日志，避免文件无限增大。合理配置 innodb_log_file_size 和 innodb_log_files_in_group 参数可以优化日志性能。

3.7 Redo Log 的删除和管理

Redo Log 的删除依赖于 Checkpoint 机制。当 Checkpoint 触发时，系统会清理已应用到数据页的日志记录，释放日志文件的空间。删除策略包括：

  • 基于 Checkpoint 的自动清理：当日志文件写满后，系统通过 Checkpoint 更新，清理已经同步的数据。
  • Redo Log 文件大小管理：innodb_log_file_size 和 innodb_log_files_in_group 的配置直接影响日志空间大小。增大日志文件可以减少 Checkpoint 频率，但会占用更多存储资源。

第四章 Bin Log

4.1 Bin Log 的作用与设计目标

Bin Log 是 MySQL 用于记录事务的逻辑变更日志，其主要作用是支持主从复制和增量数据恢复。Bin Log 记录每个事务的 SQL 语句，使得 MySQL 可以在不同节点间同步数据，或在发生故障时将数据库恢复到指定时间点。

Bin Log 的设计目标包括：

  1. 数据恢复：Bin Log 支持基于事件回放的增量恢复，即可以根据日志重放恢复到特定时间点。
  2. 主从复制：在主从架构中，主库会将事务的 SQL 变更记录写入 Bin Log，并将其发送至从库，从库通过回放这些日志实现数据同步。
  3. 跨平台数据同步：通过 Bin Log，不同平台上的 MySQL 数据库可以实现数据一致性。

4.2 Bin Log 的结构与关键组成部分

Bin Log 采用**事件（event）**的形式记录每个事务的 SQL 操作，每个事件包含了 SQL 语句的执行信息。Bin Log 的核心组成部分包括：

  1. 事件头部：包含事件的时间戳、事件类型等信息。
  2. 事件内容：记录 SQL 语句执行时的表名、字段名和修改后的值。
  3. 事件校验和：对日志事件内容进行校验，以保障日志的完整性。

以下是 Bin Log 事件结构的示意图：
Bin Log 文件
事件头部
事件内容
事件校验和

Bin Log 主要支持三种事件格式：

  • STATEMENT 格式：记录 SQL 语句本身，减少了日志大小，但在某些复杂操作上可能不精确。
  • ROW 格式：记录数据变更的行级别内容，日志更详细，适合高一致性要求的场景。
  • MIXED 格式：结合 STATEMENT 和 ROW 格式，基于 SQL 类型自动选择合适的记录方式。

4.3 Bin Log 的写入方式与时机

Bin Log 的写入方式和时机与事务的提交机制密切相关。MySQL 通过**二阶段提交（2PC）**机制确保 Bin Log 与 Redo Log 的一致性。写入过程如下：

  1. 事务执行中写入 Bin Log 缓存：在事务执行过程中，SQL 语句变更先写入 Bin Log 缓存，而不直接写入磁盘。
  2. 二阶段提交：
    • 第一阶段（预提交）：在 Redo Log 写入并持久化到磁盘后，开始 Bin Log 写入。
    • 第二阶段（正式提交）：将 Bin Log 持久化到磁盘后，将事务标记为提交成功。

二阶段提交（2PC）确保了事务的一致性，即在事务提交后，主库和从库能达到一致状态。

Transaction BinLog RedoLog 第一阶段预提交 写入 Bin Log 缓存 持久化 Bin Log 标记事务提交完成 Transaction BinLog RedoLog

4.4 Bin Log 的使用场景

Bin Log 在 MySQL 的主从复制和数据恢复中至关重要：

  1. 主从复制：

    • 数据同步：主库将事务操作写入 Bin Log，从库读取主库的 Bin Log 并重放操作，以此保持与主库的数据一致。
    • 复制延迟监控：从库应用 Bin Log 事件的延迟是衡量主从同步性能的重要指标。

  2. 增量恢复：

    • 时间点恢复（Point-In-Time Recovery）：可以根据 Bin Log 重放事务，将数据库恢复到特定时间点。例如，如果系统在某个时刻崩溃，通过回放 Bin Log 可以恢复到崩溃前的最新状态。

示例：假设主从架构中，主库执行了一条 INSERT 语句，主库记录该操作至 Bin Log。从库会定期读取主库的 Bin Log 并在本地执行相同的 INSERT 操作，从而保持数据同步。

4.5 Bin Log 文件的存储管理与配置

Bin Log 文件是按顺序生成的，每次生成新文件都会创建一个新的 Bin Log 文件。MySQL 提供了多种管理策略来优化 Bin Log 文件的存储：

  1. Bin Log 文件大小：

    • max_binlog_size 参数控制单个 Bin Log 文件的最大大小。超过该值时，MySQL 会生成新的 Bin Log 文件。
    • 调整 Bin Log 文件大小可以平衡性能与存储空间，避免单个日志文件过大导致的查询效率低下。

  2. 日志保留策略：

    • 自动删除策略：通过 expire_logs_days 参数设置日志保留的天数。超过设定天数的 Bin Log 将自动删除。
    • 手动清理：管理员可以手动删除过期的 Bin Log 文件，释放存储空间。

  3. Bin Log 索引文件：MySQL 通过 Bin Log 索引文件（通常为 mysql-bin.index 文件）记录所有 Bin Log 文件的路径，方便日志管理和查找。

4.6 Bin Log 的删除与管理

MySQL 提供了多种方式来删除和管理 Bin Log，以确保日志文件不会无限制增大。常见的管理方式包括：

  1. 自动删除：通过设置 expire_logs_days 参数，MySQL 会自动删除超过设定天数的 Bin Log 文件。
  2. 手动删除：管理员可以通过 PURGE BINARY LOGS 命令手动删除不再需要的日志文件。
  3. Bin Log 文件清理策略：
    • 频繁删除 Bin Log 会影响增量恢复和主从复制的操作。因此，在高并发的系统中，应平衡删除频率与 Bin Log 生成速度。

4.7 Bin Log 与 Redo Log 的对比

特性Redo LogBin Log
记录内容数据页物理变更SQL 逻辑变更
主要作用数据持久性、崩溃恢复主从复制、增量恢复
写入方式顺序写入，循环日志追加写入，顺序文件
写入时机每次数据变更时二阶段提交，事务提交时写入
适用场景高并发写入场景、数据恢复主从同步、跨节点增量数据恢复
删除方式基于 Checkpoint 定期清理手动或自动删除，根据保留天数清理

4.8 Bin Log 配置示例

以下为常用的 Bin Log 配置示例，可以根据业务需求调整：

# 启用 Bin Log
log_bin = /var/lib/mysql/binlog

# 设置 Bin Log 格式
binlog_format = ROW

# 设置单个 Bin Log 文件的大小
max_binlog_size = 100M

# 自动清理日志，保留 7 天
expire_logs_days = 7

第五章 Undo Log

5.1 Undo Log 的作用与设计目标

Undo Log 是 InnoDB 存储引擎中的一种逻辑日志，主要用于事务回滚和多版本并发控制（MVCC）。其设计目标包括：

  1. 实现事务回滚：当事务需要回滚或因异常终止时，Undo Log 可以恢复数据到事务开始前的状态，保障数据库的一致性。
  2. 支持多版本并发控制（MVCC）：Undo Log 保存数据的历史版本，使得多个事务在读取时可以获取一致性视图，避免读写冲突。
  3. 隔离性保障：在隔离级别为 REPEATABLE READ 的场景下，Undo Log 通过维护数据的多版本，保障事务的隔离性。

5.2 Undo Log 的工作原理与结构

Undo Log 记录每条数据的历史版本，即在每次数据变更前，将变更前的数据存储到 Undo Log 中。Undo Log 的结构如下：

  1. 回滚段（Rollback Segment）：InnoDB 中的 Undo Log 是按照回滚段组织的，每个回滚段包含多个 Undo Log 条目，用于记录不同的事务。
  2. 事务链表：每个事务在执行数据变更时，会生成一个 Undo Log 条目，这些条目形成链表以便于快速定位到历史版本。
  3. 历史数据内容：Undo Log 保存的数据页的旧版本，支持回滚操作和多版本读取。

示例：假设事务 T1 更新了一条记录 A=10 为 A=20，则在更新操作执行前，InnoDB 会在 Undo Log 中记录 A=10。如果事务 T1 需要回滚，则可以通过 Undo Log 恢复数据 A=10。

以下是 Undo Log 的基本结构图：
Undo Log
回滚段
事务链表
历史数据内容

5.3 Undo Log 的写入方式与回滚机制

Undo Log 的写入方式与回滚过程如下：

  1. 写入 Undo Log：在事务开始时，所有的数据变更都需要在执行之前先将原始数据写入 Undo Log。

    • 记录变更前的值：Undo Log 保存数据页中被修改行的原始值，以便于回滚时使用。
    • 链表结构：每个事务的 Undo Log 条目形成链表结构，可以按时间顺序追溯数据的历史状态。

  2. 事务回滚过程：

    • 在事务回滚时，系统会根据 Undo Log 链表依次撤销所有已执行的更改，将数据恢复到事务开始前的状态。
    • 逐条回滚：每个 Undo Log 记录被应用以恢复数据，直到事务的所有变更都被撤销。

  3. 自动清理机制：

    • Undo Log 会在事务提交后保留一段时间，通常用于多版本控制。只有当没有任何事务引用该 Undo Log 记录时，系统才会自动清理该记录。

5.4 Undo Log 在 MVCC 中的作用

Undo Log 在实现**多版本并发控制（MVCC）**中发挥了关键作用。在 MySQL 的 REPEATABLE READ 隔离级别下，通过保存每个事务的数据版本，InnoDB 能够提供一致性视图，使得读操作不受其他事务的写操作影响。

  1. 历史版本链：每次数据变更会生成一个新的 Undo Log 记录，通过版本链保存数据的多个历史版本。
  2. 一致性视图：当读操作发生时，InnoDB 根据事务的版本号，获取符合当前事务版本的最新数据版本，以提供一致的视图。
  3. 减少锁冲突：由于 MVCC 机制，读操作可以不加锁地读取历史版本，避免了读写冲突，提高了并发性能。

示例：在 MVCC 下，如果事务 T1 修改了一条记录 A=10 为 A=20，此时另一事务 T2 开始执行并读取 A，T2 将看到 A=10，因为 T2 的一致性视图中 A 尚未被 T1 修改。

5.5 Undo Log 的适用场景与存储管理

Undo Log 的适用场景包括：

  1. 事务回滚：在事务失败或执行 ROLLBACK 时，通过 Undo Log 恢复数据到原始状态。
  2. 高并发读写场景：在需要 REPEATABLE READ 隔离级别的高并发环境中，Undo Log 为 MVCC 提供支持，减少读写冲突。
  3. 查询一致性保障：为查询操作提供一致性视图，使得在并发读写的场景下也能实现读一致性。

在存储管理方面，Undo Log 的设计采取了回滚段（Rollback Segment）和 Undo Tablespace 机制。管理员可以通过 innodb_undo_tablespaces 参数配置 Undo Tablespace 的数量。回滚段的数量和 Undo Tablespace 的合理配置可以优化系统性能。

5.6 Undo Log 的删除和管理

Undo Log 的清理是通过 InnoDB 的自动清理机制完成的：

  1. 提交事务后清理：当事务提交后，系统会检测是否有其他活跃事务引用该 Undo Log 记录，如果没有引用，则该记录会被标记为可清理。
  2. 历史版本的删除：如果没有事务引用某个 Undo Log 的历史版本记录，InnoDB 会自动回收空间，避免 Undo Log 文件无限增长。
  3. Undo Tablespace 的管理：通过合理配置 Undo Tablespace 的数量，可以提高 Undo Log 的清理效率。

5.7 Undo Log 与 Redo Log 的对比

特性Undo LogRedo Log
记录内容数据的历史版本数据页物理变更
主要作用事务回滚、MVCC 支持数据持久性、崩溃恢复
写入方式变更前记录历史版本顺序写入，循环日志
写入时机每次数据变更之前每次数据变更时
适用场景事务隔离、回滚、多版本控制高并发写入、快速恢复
删除方式提交后自动清理历史版本基于 Checkpoint 定期清理

5.8 Undo Log 配置示例

以下为常用的 Undo Log 配置示例：

# 配置 Undo Tablespace 数量
innodb_undo_tablespaces = 2

# Undo Tablespace 文件的最大大小
innodb_undo_log_truncate = 1
innodb_max_undo_log_size = 1G

第六章 Redo Log、Bin Log 和 Undo Log 的对比与协作关系

6.1 三种日志的整体对比

Redo Log、Bin Log 和 Undo Log 各自记录了不同的信息，承担着不同的角色。以下是它们的整体对比：

特性Redo LogBin LogUndo Log
记录内容物理数据页变更SQL 逻辑操作数据历史版本
作用持久性保障、崩溃恢复数据恢复、主从复制事务回滚、MVCC
写入方式顺序写入，循环日志追加写入，顺序文件变更前写入，链表管理
写入时机数据变更时记录事务提交时记录事务中记录变更前的历史版本
删除方式基于 Checkpoint 定期清理手动或自动删除提交后自动清理
适用场景高并发写入、崩溃恢复主从同步、时间点恢复回滚、多版本控制、高并发读写
性能影响顺序 IO 提升写入性能存储和磁盘消耗相对较大空间消耗大，需合理管理

6.2 Redo Log 与 Bin Log 的协同机制

Redo Log 和 Bin Log 的协同机制主要体现在**事务的二阶段提交（2PC）**上，以保证数据一致性。Redo Log 负责物理数据页的持久性，而 Bin Log 负责记录逻辑 SQL 操作的提交顺序。在事务提交时，通过 2PC 机制确保二者的同步：

  1. 第一阶段：预提交

    • 将事务的物理变更写入 Redo Log，并持久化到磁盘，以确保数据变更的持久性。

  2. 第二阶段：正式提交

    • 将 Bin Log 写入磁盘并标记为提交。
    • 更新 Redo Log 的提交标记，事务状态正式变为已提交。

这种二阶段提交机制确保了 Bin Log 和 Redo Log 的一致性，从而避免了在主从复制或崩溃恢复时出现数据不一致的问题。

Transaction BinLog RedoLog 预提交 Redo Log 写入 Bin Log 缓存 持久化 Bin Log 更新提交标记 Transaction BinLog RedoLog

6.3 Undo Log 与 Redo Log 的协作关系

Redo Log 和 Undo Log 的协同机制确保了事务在执行过程中的一致性与回滚能力：

  1. 事务开始时：每当事务对数据进行变更时，先将变更前的数据保存到 Undo Log，以便在回滚时可以恢复原始状态。
  2. 事务回滚：若事务失败，通过 Undo Log 恢复未提交的变更，确保数据的完整性。
  3. Redo Log 持久化：事务提交时，Redo Log 记录物理变更，保障数据页的持久性。

在这种协作下，Undo Log 负责记录未提交的变更，而 Redo Log 负责持久化已提交的变更，从而实现了数据库的事务一致性。

6.4 三种日志的协作关系示例

为了更好地理解 Redo Log、Bin Log 和 Undo Log 的协作关系，以下是一个事务示例：

示例：假设一个事务 T1 执行了以下操作：

  1. 开始事务
  2. 更新一条记录 A=10 为 A=20
  3. 提交事务

在该事务中，三种日志的协作流程如下：

  1. 写入 Undo Log：事务 T1 修改 A 时，先在 Undo Log 中记录 A=10，以便于在回滚时恢复。
  2. 写入 Redo Log：变更操作执行后，将物理页的变更记录写入 Redo Log Buffer。
  3. 写入 Bin Log：事务准备提交时，将 SQL 操作写入 Bin Log。
  4. 二阶段提交：通过二阶段提交机制，Bin Log 和 Redo Log 持久化到磁盘，标记事务提交完成。

通过这种协作，Redo Log 和 Undo Log 分别负责持久化与回滚，Bin Log 负责数据同步和恢复，保障了数据的完整性和一致性。

6.5 三种日志的优化与配置建议

在高并发场景下，合理配置 Redo Log、Bin Log 和 Undo Log 是保障系统性能的关键。以下为一些优化建议：

  1. Redo Log 优化：

    • 调整 innodb_log_file_size 和 innodb_log_files_in_group 配置，以减少 Checkpoint 频率，提高写入性能。
    • 设置合适的 innodb_flush_log_at_trx_commit，平衡事务提交性能与持久性。

  2. Bin Log 优化：

    • 选择合适的 binlog_format。ROW 格式在高一致性要求场景下更优，但文件较大；STATEMENT 格式文件小，适合一致性要求低的场景。
    • 通过 expire_logs_days 控制 Bin Log 的保留天数，避免日志文件过大。

  3. Undo Log 优化：

    • 通过 innodb_undo_tablespaces 增加 Undo Tablespace 数量，提高多版本控制的效率。
    • 设置 innodb_max_undo_log_size 以控制 Undo Log 文件的最大大小，避免空间浪费。

6.6 三种日志的选择和使用场景分析

根据实际应用场景，可以有选择地调整三种日志的配置，以更好地满足业务需求。

应用场景优化方向
高并发事务写入增大 innodb_log_file_size 提升 Redo Log 性能
主从同步和灾备恢复使用 ROW 格式 Bin Log 提高一致性
高读写隔离需求增加 Undo Tablespace 支持更多历史版本

第七章 总结

7.1 Redo Log、Bin Log 和 Undo Log 的核心作用回顾

在 MySQL 的 InnoDB 存储引擎中，Redo Log、Bin Log 和 Undo Log 共同构建了一个稳健的日志系统，为数据库的事务持久性、数据一致性和并发隔离性提供了重要保障：

  1. Redo Log：主要用于数据的持久性保障和崩溃恢复。通过预写日志（Write-Ahead Logging, WAL）机制，Redo Log 记录了物理页的变更，使得系统在崩溃后能够基于日志恢复到最新状态。Redo Log 的顺序写入方式将磁盘随机 IO 转化为顺序 IO，有效提升了写入性能。

  2. Bin Log：主要用于逻辑数据恢复和主从复制。Bin Log 记录了每个事务的 SQL 操作，适用于数据的主从同步和时间点恢复（Point-In-Time Recovery）。在事务提交时，通过二阶段提交确保 Redo Log 和 Bin Log 的一致性，保障了主从数据库的一致性。

  3. Undo Log：主要用于事务回滚和多版本并发控制（MVCC）。Undo Log 记录了每个事务的历史版本，支持 REPEATABLE READ 隔离级别下的多版本控制（MVCC），保障读写隔离。Undo Log 使得回滚操作能够恢复到事务开始前的状态，从而确保数据一致性。

7.2 三种日志的关键机制对比

Redo Log、Bin Log 和 Undo Log 在设计和应用上各有侧重。以下是三者的机制对比：

机制Redo LogBin LogUndo Log
日志内容数据页的物理变更SQL 操作的逻辑记录变更前的历史数据
写入方式顺序写入，循环日志追加写入，顺序文件变更前记录，链表结构
应用场景持久性保障、崩溃恢复主从同步、增量恢复事务回滚、MVCC
删除方式基于 Checkpoint 清理手动或自动删除自动清理未引用的历史版本
性能优化顺序 IO 提升写性能大数据量场景下存储和网络传输效率空间消耗高，需合理配置

7.3 日志系统的优化配置建议

合理的日志配置可以在高并发、主从同步和数据一致性要求高的系统中有效提高性能。以下是一些优化配置建议：

  1. Redo Log 配置：

    • 增大 innodb_log_file_size 可以减少 Checkpoint 频率，有助于提升高并发写入性能。
    • 配置 innodb_log_files_in_group 参数（通常 2 到 3 个文件），使得日志组可以顺序写入，减少日志文件切换带来的性能消耗。
    • 根据业务需求调整 innodb_flush_log_at_trx_commit 参数，1 代表最高持久性，适合金融或电商等高一致性场景；0 或 2 可提升事务提交性能，但持久性较低。

  2. Bin Log 配置：

    • 使用合适的 binlog_format 格式：ROW 格式适用于数据一致性要求高的场景，STATEMENT 格式更节省空间，适合一致性要求低的场景，MIXED 则在两者之间平衡。
    • 配置 max_binlog_size 控制单个日志文件大小，避免单个文件过大带来的存储和读取开销。
    • 使用 expire_logs_days 设置自动删除过期日志，减小存储消耗。

  3. Undo Log 配置：

    • 增加 innodb_undo_tablespaces 参数以分散 Undo Log 的写入压力，提高 MVCC 的并发性能。
    • 设置合理的 innodb_max_undo_log_size，避免 Undo Log 文件过大带来的存储消耗和清理压力。

7.4 日志管理中的注意事项

在管理 MySQL 日志时，开发人员需注意以下事项，以确保日志系统高效运行：

  1. 监控日志文件大小和状态：定期检查 Redo Log、Bin Log 和 Undo Log 的文件大小和使用情况，避免磁盘空间不足。
  2. 设置合理的备份策略：结合 Bin Log，可以执行基于时间点的增量备份，保障数据恢复的完整性和可操作性。
  3. 优化 Checkpoint 机制：通过合理设置 Checkpoint 触发条件，优化 Redo Log 清理时机，以减少对写性能的影响。
  4. 事务管理：尽量减少大事务的使用，因为大事务会产生大量的 Undo Log 和 Bin Log，影响系统性能。

7.5 总结

Redo Log、Bin Log 和 Undo Log 共同构建了 MySQL 强大的日志系统，为数据库的事务一致性、持久性和并发性提供了坚实的保障。通过合理配置三种日志，我们可以在数据持久性和系统性能之间取得平衡。

关注我

【MySQL】MySQL的三种log——binlog、redo log、undo log（一文带你彻底搞懂！）
miles067的博客
08-25 4680
binlog其实在日常的开发中听得很多的，因为很多时候数据的更新就依赖着binlog。举个简单的例子：我们的数据是保存在数据库里边的，现在我们对某个商品的某个字段的内容改了（数据库变更），而用户检索出的来数据是走搜索引擎的。为了让用户能够收到最新的数据，我们需要把引擎的数据也改掉。通俗来讲——数据库的变更，搜索引擎的数据也要变更于是，我们就会监听binlog的变更，如果binlog有变更了，那我们就需要将变更写到对应的数据源当中。什么是binlog。
MySQL三大日志——binlog、redoLog、undoLog详解
想着百万年薪努力的小赵
06-25 5万+
我们都知道，事务的四大特性里面有一个是持久性，具体来说就是只要事务提交成功，那么对数据库做的修改就被永久保存下来了，不可能因为任何原因再回到原来的状态。那么mysql是如何保证一致性的呢？最简单的做法是在每次事务提交的时候，将该事务涉及修改的数据页全部刷新到磁盘中。但是这么做会有严重的性能问题，主要体现在两个方面： 1）、 因为Innodb是以页为单位进行磁盘交互的，而一个事务很可能只修改一个数据页里面的几个字节，这个时候将完整的数据页刷到磁盘的话，太浪费资源了！ 2）、 一个事务可能涉及修改多个数据页，并
MySQL 的 binglog、redolog、undolog
sekever的博客
04-08 3485
我们在每个修改的地方都记录一条对应的 redo 日志显然是不现实的，因此实现方式是用时间换空间，我们在数据库崩了之后用日志还原数据时，在执行这条日志之前，数据库应该是一个一致性状态，我们用对应的参数，执行固定的步骤，修改对应的数据。1，MySQL 就是通过 undolog 回滚日志来保证事务原子性的，在异常发生时，对已经执行的操作进行回滚，回滚日志会先于数据持久化到磁盘上（因为它记录的数据比较少，所以持久化的速度快），当用户再次启动数据库的时候，数据库能够通过查询回滚日志来回滚将之前未完成的事务。
【MYSQL】MYSQL 的学习教程（五）之 MYSQL 日志文件：undo、redo、bin log
sco5282的博客
12-22 1289
阶数：一个节点最多有多少个孩子节点。（一般用字母m表示）关键字：节点上的数值就是关键字度：一个节点拥有的子节点的数量。B- 树（B树）是一种平衡的多叉树，它比较适用于对外查找一颗 m 阶的 B- 树，有以下特征：根结点至少有两个子女；每个非根节点所包含的关键字个数 j 满足：⌈m/2⌉ - 1
MySql三大日志
qq_38482920的博客
10-12 1515
MySQL日志 主要包括错误日志、查询日志、慢查询日志、事务日志、二进制日志几大类。其中，比较重要的还要属二进制日志binlog（归档日志）和事务日志redo log（重做日志）和undo log（回滚日志）。 redoLog redo log（重做日志）是InnoDB存储引擎独有的，它让MySQL拥有了崩溃恢复能力。 比如MySQL实例挂了或宕机了，重启时，InnoDB存储引擎会使用redo log恢复数据，保证数据的持久性与完整性。 MySQL中数据是以页为单位，你查询一条记录...
MySQL的redo log、undo log、binlog
12-14
MySQL数据库中有多种日志文件，其中最重要的三种是重做日志（redo log）、回滚日志（undo log）和二进制日志（binlog）。重做日志确保事务的持久性，回滚日志用于事务回滚，而二进制日志则用于数据复制和恢复。 1. ...
MySQL 三大日志：binlog、redo log 和 undo log 使用与原理
Panda的学习日常
09-17 911
文章目录binlogbinlog日志格式binlog 使用场景binlog 刷盘时机查看 binlog 日志redo logredo log日志格式redo log使用场景redo log刷盘时机LSNredo log与binlog区别为什么 binlog 没有 crash-safe 能力两阶段提交怎么保证两份日志之间的逻辑一致组提交undo log事务提交undo log处理过程insert undo logupdate undo logpurge 线程的清理过程MySQL 崩溃恢复 日志是mysql数
MySQL事务，从redo log、bin log、undo log说起...
Java Punk
07-20 935
通过本讲，你将学到redo log、bin log、undo log日志系统的产生、释放过程，作用，以及与事务（ACID）的关系
MySQL日志篇之undo-log、redo-log、bin-log
vbgesab的博客
07-14 975
叨叨絮絮下来，就大致将MySQL中的一些常见、较为重要的日志讲明白啦，其实重点搞清楚即可，其他的会在后续篇章中再次提到，最后稍微总结一下这三个比较核心的日志：•undo-log：主要用于实现事务ACID原则中的原子性和MVCC机制。•redo-log：主要用于实现事务原则中的持久性，确保事务提交后就不会丢失。•bin-log：主要结合redo-log实现事务原则中的一致性，确保事务提交前后，数据的一致。
MySQL四种日志binlog/redolog/relaylog/undolog
程序猿进阶
08-08 1768
因为功能的不同，redo log 存储的是物理数据的变更，如果我们内存的数据已经刷到了磁盘了，那redo log的数据就无效了。这也应该容易理解，毕竟回滚嘛，跟需要修改的操作相反就好，这样就能达到回滚的目的。的存在为了：当我们修改的时候，写完内存了，但数据还没真正写到磁盘的时候。时，并不是马上就刷入中继日志里，而是由操作系统决定何时来写入，虽然安全性降低了，但减少了大量的磁盘。中继日志里，这样是最安全的，因为在崩溃的时候，你最多会丢失一个事务，但会造成磁盘的大量。我们还是会对这次的事务回滚，将无效的。
大厂基本功 | MySQL 三大日志 ( binlog、redo log 和 undo log ) 的作用？
m0_73257876的博客
08-24 1200
MySQL InnoDB 引擎使用redo log(重做日志)保证事务的持久性，使用undo log(回滚日志)来保证事务的原子性。MySQL数据库的数据备份、主备、主主、主从都离不开binlog，需要依靠binlog来同步数据，保证数据一致性。
MySQL中的redo log、 undo log、bin log
最新发布
weixin_61669379的博客
09-10 1513
redo log（重做日志）是MySQL InnoDB存储引擎中非常重要的一部分，用于保证数据库的持久性和崩溃恢复。它记录了对数据页所做的所有修改操作，确保在系统崩溃或其他意外情况下、数据库可以通过redo log进行恢复，使数据保持一致。
MySQL三大日志(binlog、redo log和undo log)详解
大河之犬的博客
01-17 2345
redo log（重做日志）是InnoDB存储引擎独有的，它让MySQL拥有了崩溃恢复能力。比如MySQL实例挂了或宕机了，重启时，InnoDB存储引擎会使用redo log恢复数据，保证数据的持久性与完整性。MySQL中数据是以页为单位，你查询一条记录，会从硬盘把一页的数据加载出来，加载出来的数据叫数据页，会放入到中。后续的查询都是先从中找，没有命中再去硬盘加载，减少硬盘IO开销，提升性能。更新表数据的时候，也是如此，发现里存在要更新的数据，就直接在里更新。
MySQL的redo log 、binlog和undolog
加油，努力，认真
04-18 4864
redo log部分 1、为什么需要redo log？ redo log 最主要的作用就是用于数据库异常宕机的恢复工作。 假如数据库永远不会发生异常宕机，那么其实根本不需要redo log，因为innodb中有线程不断的做把脏页刷新到磁盘的工作，数据库如果一直不宕机，就不会出现问题。 被划掉的线的部分的理解的产生是因为在极客时间《mysql实战45讲》的课程中，老师就是这么说的，所以就直接这么写了。但在后续的学习中，我查阅了《MySQL技术内幕-InnoDb存储引擎的实现》这本书，发现了最开始的理解并不
理解MySQL的日志 redo、undo、binlog
STRANGE-P 的博客
11-09 560
在 InnoDB 中，事务中的 delete 操作实际上并不是真正的删除掉数据行，而是一种 Delete Mark 操作，在记录上标识 Delete_Bit，而不删除记录，真正的删除是后台 purge线程去完成。比如，一个事务在修改当前一个页中某几条记录，同时还有其他事务在对同一个页中另几条记录进行修改，所以为保证不影响其他事务正在进行的工作，不能将一个页回滚到事务开始的样子。在执行事务的过程中，每执行一条语句，可能会产生多条redo日志，且这些redo日志是按照产生的顺序写入磁盘的，也就是。
【MySQL】redo、undo、binlog日志的作用和实现原理
程序猿周周的博客
05-14 2466
🌟 前言 🐶 作者简介：大家好，我是周周，目前就职于国内短视频小厂BUG攻城狮一枚。 💻个人主页：程序猿周周 📖专题系列：Java面试总结 🤺 如果文章对你有帮助，记得👍点赞👍、👀关注👀➕👌收藏👌，一键三连哦，你的支持将成为我最大的动力。 文章目录🌟 前言1 概述1.1 日志分类1.2 日志作用1.2.1 错误日志1.2.2 慢查询日志1.2.3 一般查询日志2 redo 日志2.1 整体流程2.2 持久化2.3 刷盘策略2.4 两次写功能3 undo 日志4 binary 日志4.1 基础概述4.2
MySQL日志系统：redo log、binlog、undo log 区别与作用
热门推荐
Top5软件工程硕士，先后在京东、字节从事多年Java后端开发、实时和离线大数据开发
03-13 11万+
日志系统主要有redo log(重做日志)和binlog(归档日志)。redo log是InnoDB存储引擎层的日志，binlog是MySQL Server层记录的日志， 两者都是记录了某些操作的日志(不是所有)自然有些重复（但两者记录的格式不同）。 图来自极客时间的mysql实践,该图是描述的是MySQL的逻辑架构。 redo log日志模块 redo log是InnoDB存储引擎层的...
MySQL中的重做日志（redo log），回滚日志（undo log），以及二进制日志（binlog）的简单总结...
weixin_33805992的博客
01-28 1861
  MySQL中有六种日志文件，分别是：重做日志（redo log）、回滚日志（undo log）、二进制日志（binlog）、错误日志（errorlog）、慢查询日志（slow query log）、一般查询日志（general log），中继日志（relay log）。其中重做日志和回滚日志与事务操作息息相关，二进制日志也与事务操作有一定的关系，这三种日志，对理解MySQL中的事务操作有着重...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值