Mysql 日志RedoLog

原创 于 2025-11-12 02:00:00 发布 · 804 阅读 · 18 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#mysql #数据库 #redo log

一、Redo Log 的作用

  1. 保证事务持久性（Durability）
    当事务提交时，InnoDB 会先将修改内容写入 Redo Log，然后再写入磁盘数据页。即使数据库突然宕机，也可以通过 Redo Log 恢复已提交事务的数据。

  2. 崩溃恢复（Crash Recovery）
    数据库重启时，InnoDB 会根据 Redo Log，将未持久化到数据页的已提交事务操作“重做”，保证数据一致性。

  3. 提升性能
    利用 Redo Log，可以先将日志顺序写入磁盘，后续再批量刷新数据页，减少随机写，提高性能。

二、Redo Log 的结构

1. 文件结构

  • Redo Log 由一组固定大小的日志文件组成，默认名为 ib_logfile0, ib_logfile1 等。
  • 可以通过参数 innodb_log_file_size 和 innodb_log_files_in_group 配置大小和数量。

2. 日志内容

  • Redo Log 记录的是数据页的物理修改（页号、偏移量、修改内容等），属于物理日志。
  • 不记录 SQL 语句，只记录数据页的变化。

3. 日志环形写入

  • Redo Log 文件组成一个环形空间，写满后会循环覆盖旧日志（前提是旧日志已经“刷盘”并不再需要）。

三、Redo Log 的工作流程

1. 写入流程

  1. 事务修改数据页时，先将修改内容写入 Redo Log Buffer（内存）。
  2. 根据事务提交策略（如 innodb_flush_log_at_trx_commit），将 Redo Log Buffer 刷新到磁盘文件（ib_logfile）。
  3. 后续由后台线程（如 InnoDB 的 checkpoint 机制）将数据页同步到磁盘。

2. 刷盘策略

  • innodb_flush_log_at_trx_commit 参数控制 Redo Log 的刷盘时机：
    • 1：每次事务提交都立即刷盘（最安全，最慢）。
    • 2：每秒刷盘一次，事务提交只写入内存（性能高但有丢失风险）。
    • 0：后台线程周期性刷盘，事务提交只写入内存（风险最大）。

3. Checkpoint 机制

  • Checkpoint 是指将数据页的修改同步到磁盘，并标记哪些 Redo Log 已经“安全”。
  • Checkpoint 后，旧的 Redo Log 可被覆盖，保证日志空间不会无限增长。

四、Redo Log 的恢复过程

  • 数据库异常宕机后重启，InnoDB 会扫描 Redo Log，从最近的 Checkpoint 开始，将未落盘的数据页修改“重做”到数据文件，保证数据一致性。

五、Redo Log 与 Undo Log 的区别

方面Redo LogUndo Log
作用崩溃恢复、持久化回滚、MVCC、快照读
内容记录数据页的物理修改记录数据修改前的旧值
写入时机数据修改后数据修改前
事务提交时处理需要持久化写盘部分立即清理，部分延迟清理
存储位置ib_logfile* 文件Undo 表空间

六、Redo Log 相关参数

  • innodb_log_file_size：单个 Redo Log 文件大小，建议根据写入压力适当增大。
  • innodb_log_files_in_group：Redo Log 文件数量，通常为2。
  • innodb_flush_log_at_trx_commit：控制刷盘时机，影响性能与安全性。
  • innodb_log_buffer_size：Redo Log Buffer 大小。

七、性能优化建议

  1. 合理设置 Redo Log 文件大小
    大文件可以减少 checkpoint 频率，提高性能，但恢复时间也会变长。

  2. 根据业务安全需求设置刷盘策略
    对数据安全性高要求建议设置为1，对性能要求高可考虑2或0（但有丢失风险）。

  3. 监控 Redo Log 使用情况
    可通过 SHOW ENGINE INNODB STATUS; 查看 Redo Log 写入和 checkpoint 进度。

八、典型问题分析

  1. Redo Log 文件过小

    • 容易频繁 checkpoint，影响性能。
    • 建议根据业务写入压力适当增大。

  2. 刷盘策略不合理

    • 设置为0或2可能导致数据丢失，需权衡性能和安全。

  3. 恢复时间长

    • Redo Log 文件越大，崩溃恢复时间越长。

九、Redo Log 与 Binlog 的区别

方面Redo LogBinlog
归属InnoDB引擎MySQL Server层
类型物理日志逻辑日志（SQL/Row）
作用崩溃恢复主从复制、点时间恢复
写入时机数据页修改后事务提交后
可见性只有InnoDB用用户可读、可解析

十、源码简析

  • Redo Log 相关源码主要在 log0log.cc、log0recv.cc、log0write.cc 等文件中。
  • 实现了日志缓冲、刷盘、恢复、checkpoint 等机制。

十一、实践建议

  1. 业务高并发写入时，适当增大 Redo Log 文件大小。
  2. 定期监控 Redo Log 空间和 checkpoint 进度，避免日志写满导致阻塞。
  3. 根据业务安全要求调整刷盘策略，避免数据丢失。
  4. 升级 Redo Log 文件配置时，需先关闭数据库，删除旧日志文件。

十二、Redo Log 的内部结构

1. 日志条目（Log Record）

Redo Log 记录的是数据页的物理修改。每个日志条目包含：

  • 页号（Page Number）
  • 修改偏移量（Offset）
  • 修改前后的数据
  • 操作类型（插入、更新、删除）
  • 事务ID
  • 日志序列号（LSN，Log Sequence Number）

2. LSN（日志序列号）

  • 每次写入 Redo Log 时都会生成递增的 LSN。
  • 数据页也会标记自己的 LSN，表示其最新一次被修改的日志序列号。
  • Checkpoint 也会记录一个 LSN，表示数据文件已经持久化到哪个位置。

3. 环形日志文件

  • Redo Log 文件以环形方式写入。
  • 当前写入点称为 write pos，checkpoint点称为 checkpoint pos。
  • 只有 checkpoint 之前的日志可以被覆盖，之后的日志必须保留。

十三、Redo Log 的写入流程

  1. 数据页修改时
    • 首先将修改记录写入 Redo Log Buffer（内存）。
  2. 事务提交时
    • 根据 innodb_flush_log_at_trx_commit 参数，将 Redo Log Buffer 刷新到磁盘日志文件。
  3. 后台定期刷盘
    • 即使事务未提交，后台线程也会周期性将 Redo Log Buffer 刷新到磁盘，防止数据丢失。

十四、Checkpoint机制详解

Checkpoint 的作用

  • 将数据页的修改同步到磁盘。
  • 标记哪些 Redo Log 已经不再需要，可以被覆盖。
  • 降低崩溃恢复时需要重做的日志量。

Checkpoint 触发时机

  • Redo Log 文件空间不足时，强制触发 checkpoint。
  • 后台线程定期触发 checkpoint。
  • 事务提交频繁时，可能更快触发。

Checkpoint 的实现步骤

  1. 找出需要持久化的数据页（脏页）。
  2. 将这些页写入磁盘。
  3. 更新 checkpoint LSN，释放旧的日志空间。

十五、崩溃恢复原理

  1. 数据库重启时

    • InnoDB 读取 checkpoint LSN。
    • 从 checkpoint 之后的 Redo Log 开始，依次“重做”所有未落盘的数据页修改。
    • 保证所有已提交事务的数据都能恢复。

  2. 未提交事务的数据不会被重做

    • Redo Log 只保证已提交事务的持久性，未提交事务会通过 Undo Log 回滚。

十六、Redo Log 与 Binlog 的两阶段提交

为什么需要两阶段提交？

  • Redo Log 属于 InnoDB 层，Binlog 属于 MySQL Server 层。
  • 事务提交时需要保证两者一致，否则主从复制、点时间恢复会出问题。

两阶段提交流程

  1. 写入 Redo Log（prepare）
    • 事务先写入 Redo Log，标记为“准备提交”。
  2. 写入 Binlog
    • 再写入 Binlog。
  3. 提交 Redo Log（commit）
    • 最后将 Redo Log 标记为“已提交”。

这样即使宕机，只要 Binlog 和 Redo Log都完整，就能保证数据一致性。

十七、常见问题分析

  1. Redo Log 写满导致阻塞

    • 日志空间不够，无法继续写入，业务可能阻塞。
    • 解决方法：增大日志文件大小，优化 checkpoint 频率。

  2. 崩溃恢复慢

    • 日志文件太大，恢复时需要重做的操作太多。
    • 解决方法：平衡日志文件大小与恢复速度。

  3. 刷盘策略不合理导致数据丢失

    • 设置为0或2时，可能丢失部分已提交事务。
    • 解决方法：线上建议设置为1，保证安全。

十八、实际运维建议

  1. 合理规划 Redo Log 文件大小

    • 写入压力大时建议设置为1GB及以上。
    • 需提前规划，修改需停库并删除旧日志文件。

  2. 监控 Checkpoint 和日志空间占用

    • 通过 SHOW ENGINE INNODB STATUS 监控 Log sequence number 和 Checkpoint。
    • 发现写入点接近 checkpoint 时，需关注是否有空间不足风险。

  3. 定期测试恢复流程

    • 定期做崩溃恢复演练，确保 Redo Log 能正确恢复数据。

  4. 刷盘策略选择

    • 生产环境建议 innodb_flush_log_at_trx_commit=1，保证事务安全。
    • 测试环境可以用2或0提升性能。

十九、源码简析（补充）

  • Redo Log Buffer 管理：log0buf.cc
  • 日志写入与刷盘：log0write.cc
  • 恢复流程：log0recv.cc
  • Checkpoint 实现：log0chkpt.cc

源码中大量使用 LSN 进行日志条目和数据页的关联，保证一致性。

二十、总结

Redo Log 是 InnoDB 实现事务持久性和崩溃恢复的核心机制。合理规划和监控 Redo Log，有助于提升数据库的安全性和性能。

详解MySQL重做日志redolog
禅与计算机程序设计的艺术
08-06 1367
redo log是InnoDB存储引擎独有的日志，用于在MySQL宕机时恢复数据，确保数据完整性和持久性。本文详细讲解了redo log的作用、工作机制及刷盘策略。redo log通过记录数据修改操作，结合buffer pool和刷盘机制，减少直接写磁盘的IO操作，提升数据库性能。刷盘时机包括事务提交、缓冲区空间不足、后台线程定时刷盘等。redo log的刷盘策略由参数innodb_flush_log_at_trx_commit决定，不同设置影响数据的安全性。此外，redo log与bin log的二阶段提
【MySQL】RedoLog日志和Binlog日志哪个先写的问题?
Cover_sky的博客
07-16 1340
1.自动为每个事务分配一个唯一的ID(XID)。这个ID很重要，是两阶段提交的核心2.COMMIT会被自动的分成Prepare和Commit两个阶段3.Binlog会被当作事务协调者(Transaction Coordinator) Binlog Event会被当作协调者日志binlog在2PC中充当了事务的协调者(Transaction Coordinator)由binlog来通知InnoDB引擎来执行prepare，commit或者rollback的步骤。
MySQL日志redo log详解
些许风霜罢了
10-21 1757
其中，比较重要的还要属二进制日志 binlog（归档日志）和事务日志 redo log（重做日志）和 undo log（回滚日志）。比如 MySQL 实例挂了或宕机了，重启时，InnoDB 存储引擎会使用 redo log 恢复数据，保证数据的持久性与完整性。MySQL 中数据是以页为单位，你查询一条记录，会从硬盘把一页的数据加载出来，加载出来的数据叫数据页，会放入到。如果事务执行期间 MySQL 挂了或宕机，这部分日志丢了，但是事务并没有提交，所以日志丢了也不会有损失。
MySQL日志redo log、undo log、bin log简介
peng_shakalaka的博客
10-15 1914
undo log：回滚日志，原子性，实现事务回滚和MVCC，引擎层实现redo log：重做日志，崩溃恢复，持久性 ，引擎层实现bin log：主从复制，数据备份，Server层实现。
深入分析MySQL事务日志-Redo Log日志
緑水長流*z
09-24 6812
事务的隔离性是通过锁实现，而事务的原子性、和持久性则是通过事务日志实现。在MySQL中，事务日志分为两类，一个是Redo Log，也叫重做日志，另一个是Undo Log，也叫回滚日志；其中Redo Log保证事务的，Undo Log保证的是事务的；
MySQL：redo log（重做日志）
AWSDN的博客
09-12 1415
本文主要介绍MySQL中redo log的内容
MySQL日志——redolog
欢迎指正、交流
06-18 3175
在mysql提交一个事务后，这个事务所作的数据修改并不会直接保存到磁盘文件中，而是先保存在buffer pool缓冲区中，在需要读取数据时，先从缓冲区中找，没找到再去磁盘找，加之每次提交事务都将数据写入磁盘的效率低下，所以引入了buffer pool缓冲区。因此，redo log记录了一个事务对数据页的修改，这个记录与undolog不同，是物理层面的，比如。提交一个事务后，先将redo log持久化磁盘，就可以保证这个事务修改的数据被持久化了。为什么需要redo log？
MySQL重做日志 redo log
qq_41721746的博客
06-18 476
一、引入redo log 二、redo log概念 三、磁盘、缓存结构
MySQL的redolog日志
weixin_44151292的博客
10-15 827
InnoDB的内存有缓冲池，增删改时修改缓冲池的数据，没有的话，先从磁盘加载存到缓冲区再修改。当进行增删改后，回先记录到redo log buffer中记录数据页变化，事务提交的时候会把bufffer中的变化刷新到磁盘中持久保存，这时如果出错可以通过redolog进行数据恢复。而如果脏页成功刷新到磁盘 或者涉及到的数据已经落盘，此时redolog就没有作用了，就可以删除了，所以存在的两个redolog文件是循环写的。重做日志，记录的是事务提交时数据页的物理修改，是用来实现事务的。
MySQL - redolog 图文详解
一七令
07-17 2604
和binlog不同，redolog不是二进制日志。它是物理日志，记录数据页的物理修改。用来恢复提交后的物理数据页(恢复数据页，且只能恢复到最后一次提交的位置)。redolog是innodb为了支持崩溃恢复而出现的，只记录innodb存储引擎中表的修改。层面不同binlogMySQL本身实现的日志模块，而redolog是innodb引擎层实现的。记录内容不同binlog记录的是逻辑性语句，即便是行格式形式。写入形式不同两阶段提交，后续章节会详解。写入时机不同。......
MySQL的redo log、undo log、binlog
12-14
【MySQL日志文件类型】 MySQL数据库中有多种日志文件，其中最重要的三种是重做日志（redo log）、回滚日志（undo log）和二进制日志（binlog）。重做日志确保事务的持久性，回滚日志用于事务回滚，而二进制日志则...
MySQL重做日志（redo log）总结
热门推荐
weixiaohuai的博客
06-14 1万+
一、redo log的概念 redo log，重做日志，也叫重放日志。和undo log回滚日志一样，都是在数据库发生意外时用来进行数据恢复的，通过前面一篇文章对undo log的总结，我们都知道undo log记录的是数据更新前的样子，主要保证事务的原子性；而redo log则记录的是事务执行过程中的修改情况，redo log主要保证事务的持久性。 当数据库对数据做修改的时候，需要把数据页从磁盘读到buffer pool中，然后在buffer pool中进行修改，那么这个时候buffer poo.
【面试八股总结】MySQL日志：undo log、redo log、binlog
Chesnut.
09-04 1666
MySQL中存在三种日志： undo log（回滚日志）：是 Innodb 存储引擎层生成的日志，实现了事务中的原子性，主要用于事务回滚和 MVCC。 redo log（重做日志）：是 Innodb 存储引擎层生成的日志，实现了事务中的持久性，主要用于掉电等故障恢复； binlog （归档日志）：是 Server 层生成的日志，主要用于数据备份和主从复制。
初识MYSQL —— 复合查询
LH__1314的博客
11-06 815
这里简单回顾一下基本查询的内容：（whereorder bygroup by等等）这里依旧使用empdeptno和salgrade三张表来做练习J这两个筛选条件要同时满足。根据要求，按照部门号升序、雇员工资降序排序。按照年薪进行降序排序；（根据实际情况来定）在emp表中，comm列是存在NULL的，这里就要进行判断；使用ifnull函数，如果为NULL就返回0。这里order by执行顺序在select之后，可以使用别名。根据需求，我们应该要想到一个问题：工资最高的员工可能有很多人；（不能使用。
【TRAE】AI 编程：颠覆全栈开发，基于 TRAE AI 编程完成 Vue 3 + Node.js + MySQL 企业级项目实战，从环境搭建到部署上线
最新发布
顾三殇 —— 博客空间（软件测试）
11-11 629
TRAE 三大智能体构成了一套完整的 AI 协作开发体系：@Chat 智能体作为代码级助手处理日常编码任务，@Builder 智能体作为项目级构建者快速搭建原型，@Builder with MCP 则作为系统级架构师构建连接真实数据库的全栈应用。在实际开发中，最佳实践是先用 @Builder with MCP 建立全栈基础架构，再通过 @Builder 生成功能模块原型，最后利用 @Chat 进行代码优化。
mysql查看binlog日志
bagadesu的博客
11-06 416
mysql查看binlog日志
MySQL的增删改查功能合集
2401_87747173的博客
11-10 897
这里给出两组对比：这里代码的执行过程大概如下：1.先遍历表，2.取出表的每个行，带入条件（此时使用的是别名）3.把符合条件的行筛选出来 4.根据select后面的表达式进行计算。
MySQL——增删改查操作
2301_80748572的博客
11-06 691
where 条件列表] [group by 分组字段] [having 条件列表] [order by 字段列表] [limit 分页参数];当给表格所有字段赋值时，字段部分可省去，即insert into 表名 values(值1,值2...),(值1,值2...)...;insert into 表名 (字段1,字段2...) values(值1,值2...),(值1,值2...)...;(2)条件查询：select 字段列表 from 表名列表 where 条件列表;
MySQL系列之数据类型（String）
蓝萧的专栏
11-06 503
MySQL系列之数据类型（String）
mysql 如何查看 redo log 日志
03-24
<think>嗯，用户想了解如何在MySQL中查看redo log日志。首先，我得回忆一下MySQL中redo log的结构和存储方式。根据之前的引用资料，redo log包括内存中的缓冲区和磁盘上的文件，比如引用[4]提到redo log分为内存的redo log buffer和磁盘的redo log file。所以用户可能想查看这两个部分的信息，但需要知道MySQL通常不直接让用户查看redo log文件的内容，因为这些是内部的、二进制的日志，用于崩溃恢复和事务的持久性。 接下来，我需要考虑用户的实际需求。用户可能是想监控redo log的状态，比如当前的使用情况、文件大小、写入情况等，或者是想查看具体的日志内容。但直接查看文件内容可能不可行，因为redo log是二进制格式，MySQL没有提供直接的工具来解析。不过，可以通过一些系统变量或命令来获取相关信息。 根据引用[1]，提到了innodb_redo_log_capacity变量，这可能是一个新的配置参数，用于设置redo log的容量。在较新的MySQL版本中，用户可能需要查看这些参数来了解redo log的配置。此外，还有像innodb_log_files_in_group和innodb_log_file_size这样的变量，但可能在8.0之后被替换了。 另外，引用[3]和[5]提到redo log的状态，比如prepare和commit阶段，这涉及到事务的恢复过程。用户可能想通过某些命令查看当前redo log的状态，或者事务的状态。 可能的步骤包括： 1. 使用SHOW ENGINE INNODB STATUS命令，查看InnoDB的状态信息，其中包含了redo log的相关信息，比如日志序列号、写入位置等。 2. 查看系统变量，如innodb_redo_log_capacity、innodb_log_files_in_group等，来了解redo log的配置。 3. 使用性能模式（performance_schema）中的表来监控redo log的活动，比如events_waits_current表。 4. 对于实际文件，虽然不能直接查看内容，但可以查看文件的位置和大小。MySQL 8.0之后，redo log文件默认在数据目录下的#innodb_redo目录中，文件名类似redo_log_fileN。 需要注意的是，直接解析redo log文件内容需要专门的工具，这可能比较复杂，且官方不推荐。因此，用户可能需要使用间接的方法来监控和查看redo log的状态，而不是具体的内容。 另外，用户可能需要了解如何调整redo log的大小或配置，这可能涉及到修改系统变量，如引用[1]提到的innodb_redo_log_capacity。在回答时，需要区分不同MySQL版本的方法，因为8.0.30前后可能有变化。 总结下来，查看redo log的方法包括检查系统变量、InnoDB状态、文件位置以及性能模式中的监控数据。对于具体内容，可能需要使用第三方工具或MySQL的调试功能，但通常不建议这样做。</think>### 如何在MySQL中查看redo log日志？ #### 1. **查看redo log配置参数** MySQL通过系统变量控制redo log的容量和文件数量。对于MySQL 8.0.30及之后的版本，使用以下命令： ```sql SHOW VARIABLES LIKE 'innodb_redo_log_capacity'; ``` 这会显示当前分配的redo log总容量（默认约104857600字节，即100MB）[^1]。早期版本可使用`innodb_log_files_in_group`和`innodb_log_file_size`查看文件数量和单个文件大小。 #### 2. **查看redo log文件物理位置** 默认情况下，redo log文件存储在MySQL数据目录的`#innodb_redo`子目录中，文件名格式为`redo_log_fileN`（例如`redo_log_file0`）。通过以下命令定位文件路径： ```sql SHOW VARIABLES LIKE 'datadir'; ``` #### 3. **监控redo log状态** 通过`SHOW ENGINE INNODB STATUS`查看InnoDB引擎状态，重点关注`LOG`部分： ``` LOG Log sequence number 1234567890 # 当前LSN（日志序列号） Log buffer assigned up to 1234567890 # 缓冲区已分配量 Log buffer completed up to 1234567890 # 缓冲区已写入量 Log flushed up to 1234567890 # 已刷盘LSN Pages flushed up to 1234567890 # 数据页刷盘LSN ``` `Log sequence number`表示最新的日志位置，`Log flushed up to`表示已持久化的日志位置，两者的差异反映未刷盘的日志量。 #### 4. **通过性能模式监控** 启用Performance Schema后，可查询redo log相关事件： ```sql SELECT * FROM performance_schema.events_waits_current WHERE EVENT_NAME LIKE '%innodb%log%'; ``` 此方法用于分析redo log的写入等待事件，帮助诊断性能问题。 #### 5. **解析redo log内容（高级）** MySQL未提供直接解析redo log的工具，但可通过以下方法间接分析： - **启用调试模式**：编译时开启`WITH_DEBUG`选项，使用`innodb_redo_log_reader`工具（仅限开发环境）。 - **第三方工具**：如Percona的`redo_log_parser`，需谨慎使用。 #### § 注意事项 - redo log是二进制文件，直接查看需特殊工具。 - 生产环境不建议修改redo log文件，可能破坏事务一致性。 --- ###
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

猩火燎猿

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值