深入理解MySQL的Redo Log刷盘机制

最新推荐文章于 2025-04-10 13:39:02 发布
最新推荐文章于 2025-04-10 13:39:02 发布
阅读量399 收藏 1
点赞数
分类专栏： Mysql八股文 文章标签： mysql 数据库
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/tombosky/article/details/134422623
版权
MySQL的Redo Log是保障数据完整性和一致性的关键机制。本文详细介绍了Redo Log刷盘的时机，包括InnoDB存储引擎状态的影响和系统参数设置。刷盘步骤包括开启Redo Log、设置刷盘策略、备份文件以及在故障恢复时的应用。同时，通过实例展示了如何在每次事务提交时刷盘并备份Redo Log文件。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

在MySQL中，Redo Log是一种重要的日志机制，它记录了所有对数据库进行修改的操作。当数据库发生故障时，Redo Log可以帮助我们恢复到故障发生之前的状态，从而保证数据的完整性和一致性。然而，仅仅将Redo Log写入磁盘并不能确保数据的安全性，因为磁盘可能会损坏或丢失。因此，我们需要定期将Redo Log刷盘，即将其内容写入到磁盘上的一个持久化文件。本文将详细介绍Redo Log刷盘的时机，并通过实例来展示其使用方法。

在这里插入图片描述

1. Redo Log刷盘的时机

Redo Log刷盘的时机主要取决于以下几个因素：

  • InnoDB存储引擎的状态：当InnoDB存储引擎处于非正常关闭状态（如系统崩溃）时，需要强制刷盘以确保数据的完整性。
  • 系统参数设置：可以通过设置innodb_flush_log_at_trx_commit参数来控制Redo Log的刷盘时机。该参数有以下三种取值：
    • 0：表示不刷盘，由操作系统决定何时刷盘。这是默认值。
    • 1：表示每次事务提交时都刷盘。
    • 2：
了解本专栏 订阅专栏 解锁全文 超级会员免费看
【MySQL】MySQL 的 redo log 和 binlog 区别
九师兄
05-01 977
1.概述 2. 为什么需要 redo log？ redo log 主要用于 MySQL 异常重启后的一种数据恢复手段，确保了数据的一致性。 其实是为了配合 MySQL 的 WAL 机制。因为 MySQL 进行更新操作，为了能够快速响应，所以采用了异步写回磁盘的技术，写入内存后就返回。但是这样，会存在 crash后 内存数据丢失的隐患，而 redo log 具备 crash safe 的能力。 3.crash-safe 能力 为什么 redo log 具有 crash-safe 的能力，是 binlog .
MySQL 三大日志：binlog、redo log 和 undo log 使用与原理
Panda的学习日常
09-17 909
文章目录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 表数据多久刷一次盘？
「 虚幻私塾」
04-07 1475
Python微信订餐小程序课程视频 https://edu.csdn.net/course/detail/36074 Python实战量化交易理财系统 https://edu.csdn.net/course/detail/35475 前言 事情是这样的，在某乎的邀请回答中看到了这个问题： - 然后当时我没多想就啪一下写下来这样的答案： 这个其实要通过 MySQL 后台线程来刷的，在 Buffer Pool 中被修改的过的 Page（页）都会被标记成脏页，放到一个链表（Flush 链表）里。 然后 MySQ
mysql刷盘机制详解
liuzhilong的博客
01-12 9204
mysql刷脏数据在写redo之后，逻辑跟oracle一致，checkpoint/commit->内存中的redo到redolog文件->内存中的脏数据到数据盘。 但是mysql多一个环节，就是把binlog从binlogcache写入到binlog文件中。binlogcache不是共享内存，是为每个client分配的私有内存，是mysqlserver管理的。而logbuffer是共享内存，由innodb管理，属于innodb存储引擎内存。 ———————————————— 版权声明：本文为CSD
MySQL两阶段提交：日志刷盘、崩溃恢复与数据一致性的终极指南​
最新发布
qq_21330821的博客
04-10 806
MySQL通过两阶段提交协议（Prepare→Commit）保障事务原子性，协调binlog（逻辑日志）与redolog（物理日志）的刷盘顺序，解决数据不一致风险。Prepare阶段预写redolog并强制刷盘，Commit阶段写入binlog后更新日志状态，确保崩溃恢复时通过XID校验事务完整性。单日志场景会导致主从差异或数据丢失，而参数如sync_binlog=1与innodb_flush_log_at_trx_commit=1可平衡性能与安全。
mysql 的刷盘策略
weixin_38410177的博客
02-18 1851
发现线上又很多简单的update语句出现300多ms的慢sql. 慢sql排查，查看执行计划是走索引的，于是联系dba. dba更改了刷盘策略。 innodb_flush_log_at_trx_commit 和 sync_binlog mysql的"双1验证"指的是innodb_flush_log_at_trx_commit和sync_binlog两个参数设置，这两个是是控制MySQL 磁盘写入策略以及数据安全性的关键参数。下面从参数含义，性能，安全角度阐述两个参数为不同的值时对db 性能,数据的.
redo日志的刷盘策略
weixin_38629422的博客
04-28 3267
我们想要提交一个事务了，此时就会根据一定的策略把redo日志从redo log buffer里刷入到磁盘文件里去。 此时这个策略是通过 innodb_flush_log_at_trx_commit 来配置的，这个参数值共有三种策略。接下来一一为大家介绍 1.当这个参数的值为0的时候，那么你提交事务的时候，不会把redo log buffer里的数据刷入磁盘文件的，此时可能你都 提交事务了...
redolog的刷盘策略
qq_35693377的博客
07-06 542
2：实时写，延时刷。每次提交事务都将redo log写入os buffer，但并不会马上调用fsync()刷如磁盘，而是间隔1秒调fsync()刷盘。相对于每次提交都写盘和每隔1秒写盘，实施写os buffer延时刷盘是一个数据一致性与性能的之间的这种方案。提交事务时不会将redo log写入os buffer，而是每隔1秒将redo log写入os buffer并调用fsync()刷入磁盘。1：实时写，实时刷。每次提交事务都将redo log写入os buffer并调用fsync()刷入磁盘。
MySQL~Redo刷盘策略、LogBuffer缓存池和LogFile日志文件理解
zxc的博客
05-11 2919
文章目录刷盘策略不同刷盘策略演示Redo log buffer缓存区Redo log file日志文件总结 刷盘策略 Innodb在写Redo日志的时候，是先写入redo log buffer 中，然后再按照一定频率刷新到redo log file中。 这里的 一定频率 有多个选择，这些选择对应的就是不同的刷盘策略. 这里的刷盘不是指将内存中的数据刷新到磁盘，而是指从Redo日志位于内存中的缓冲区（redo log buffer）刷新到位于磁盘中的文件区（redo log file）. redo
全网最通透：MySQL 的 redo log 保证数据不丢的原理
m0_71777195的博客
08-26 927
存储引擎是 MySQL 中直接与磁盘交互部分。页是存储引擎读写数据的最小单位，一个页里可以有一条或多条表记录。MySQL 中的存储引擎有很多种，比如 InnoDB、MyISAM、Memory 等。其中最常用的是 InnoDB。而 InnoDB 是 MySQL 中唯一能够完整支持事务特性的存储引擎，也是一个高性能的存储引擎。本文要讲的「两段式提交」就发生在 InnoDB 中。...
MySQL之Redo日志刷盘策略超详细解析
qq_41473691的博客
11-10 2478
针对这种情况，Innodb给出了Innodb_flush_log_at_trx_commit参数。当提交事务的时候，去看Innodb_flush_log_at_trx_commit这个值为2，马上就会把redo log buffer中的数据更新到page cache中，但是刷盘的时间由操作系统决定。另外，innodb存储引擎有一个后台线程，每隔1秒，就会把redo log buffer中的内容写到文件系统缓存（page cache)，然后调用刷盘操作。，Innodb引擎会在写入Redo Log的时候。
MySQL数据和日志的刷盘机制以及双一配置
终生学习践行者
07-07 2989
详细介绍了MySQL数据和日志的刷盘机制以及双一配置，双一配置可以保证Mysql日志数据不丢失。
Redo Log（重做日志）的刷盘策略
m0_54187478的博客
11-02 768
Redo Log（重做日志）是 InnoDB 存储引擎中的一种关键组件，用于保障数据库事务的持久性和崩溃恢复。InnoDB 将事务所做的更改先记录到重做日志，之后再将其应用到磁盘上的数据页。刷盘策略（Flush Policy）指的是将内存中的重做日志内容刷写（写入）到磁盘的方式和时间点，以确保数据的持久性和一致性。InnoDB 使用多种策略来处理重做日志的刷盘操作：WAL（Write-Ahead Logging）：InnoDB 是一种WAL存储引擎，它要求在事务提交前将重做日志刷新到磁盘。
mysql中的Redo log
yzx3105的博客
05-15 1656
mysql 有多种日志，每种日志都有其特定的用途。redolog 是 mysql 存储引擎为 innodb 时，特有的日志。innodb 是 mysql 最常用的存储引擎，它的事务的持久性就是通过 redolog保证的。我们都知道，事务的四大特性里面有一个是持久性，具体来说就是只要事务提交成功，那么对数据库做的修改就被永久保存下来了，不可能因为任何原因再回到原来的状态。那么 mysql是如何保证一致性的呢？最简单的做法是在每次事务提交的时候，将该事务涉及修改的数据页全部刷新到磁盘中。
mysql日志刷盘
ywl470812087的博客
01-02 1048
1、sync binlog=0的时候，表示每次提交事务binlog不会马上写入到磁盘，而是先写到page cache,相对于磁盘写入来说写page cache要快得多不过在Mysql崩滚的时候会有丢失日志的风险.3、sync binlog的值大于1的时候，表示每次提交事务都先写到page cache，只有等到积累了N个事务之后才tsync写入到磁盘，同样在此没置下Mysq1崩溃的时候会有丢失N个事务日志的风险。2、sync_binlog=1的时候，表示每次提交事务都会执行fsync写入到磁盘;
谈谈 MySQL的刷盘过程 和 表数据
囚牢-峰子的博客
01-13 1373
先来看第一个问题，SQL语句变慢 原因分析 一条 SQL 语句，正常执行的时候特别快，但是有时也不知道怎么回事，它就会变得特别慢，并且这样的场景很难复现，它不只随机，而且持续时间还很短，像抖了一下。 我们通常的更新语句，只做了更新内存数据页并写redolog的写磁盘动作，但是内存中的脏页总得跟新到磁盘中，也就是flush的动作。这个flush，就会影响到SQL语句的操作。 总结一下引发 flush的场景： InnoDB 的 redo log 写满了。这时候系统会停止所有更新操作，把 che...
redo log的刷盘策略
weixin_42148897的博客
07-07 4068
事务有4种特性：原子性、一致性、隔离性和持久性。那么事务的四种特性到底是基于什么机制实现呢？事务的隔离性由锁机制实现。事务的原子性、一致性和持久性由事务的 redo 日志和 undo 日志来保证。redo log称为重做日志 ，提供再写入操作，恢复提交事务修改的页操作，用来保证事务的持久性。undo log称为回滚日志 ，回滚行记录到某个特定版本，用来保证事务的原子性、一致性。redo log是存储引擎层生成的日志，记录的是物理级别上的页修改操作，比如页号xxx，偏移量yyy，写入了zzz数据，主要是为了保
MySQL中，为什么数据页的刷盘是随机写，redolog的刷盘是顺序写？
03-13
<think>好的，我现在需要回答用户关于MySQL中数据页刷盘是随机写而redolog刷盘是顺序写的原因。首先，我需要明确用户的问题，并理解他们可能对MySQL的存储机制和日志系统不太熟悉，因此需要从基础开始逐步解释。 首先，我应该回忆一下MySQL的架构，特别是InnoDB存储引擎的部分。数据页通常是存储在表空间文件（如ibdata1或独立的.ibd文件）中的，而redo log则是用于崩溃恢复的日志文件。用户的问题涉及到这两种写入方式的区别，即为什么数据页的刷盘是随机写，而redo log是顺序写。 接下来，我需要分析数据页和redo log的不同用途。数据页是实际存储数据的结构，当数据被修改时，这些修改首先在内存中的缓冲池（buffer pool）中进行，然后异步刷新到磁盘。而redo log记录的是对数据页的物理修改，用于在系统崩溃后恢复未刷新的数据页。 然后，我应该考虑磁盘I/O的特性。顺序写比随机写快得多，因为顺序写不需要频繁移动磁头（在HDD的情况下）或减少SSD的写入放大。因此，MySQL的设计者可能将redo log设计为顺序写，以提高写入性能，确保事务的持久性（ACID中的D）能够高效完成。 对于数据页的刷盘，由于数据页分散在表空间的各个位置，当缓冲池中的脏页需要刷新到磁盘时，这些页可能分布在不同的位置，导致随机写。此外，数据页的刷盘通常是异步的，由后台线程处理，而redo log的刷盘是在事务提交时必须完成的，因此需要更高的效率，顺序写更适合这种高频、必须快速完成的场景。 可能还需要考虑Checkpoint机制，它决定了哪些脏页需要刷盘，而redo log的循环使用方式也支持顺序写入。此外，redo log的文件是预先分配的，以固定大小循环使用，这样写入时总是追加到文件的末尾，形成顺序写。 用户可能存在的疑问包括：为什么数据页不能也顺序写？答案可能是因为数据页的位置由主键、索引等结构决定，无法保证连续，而redo log的结构设计允许连续写入。此外，数据页的刷盘策略（如LRU算法）可能导致随机访问模式。 需要确保解释清晰，避免技术术语过多，但又要准确。可能需要用比喻，比如将redo log比作连续记录操作的日志，而数据页像是分散在仓库中的货物，每次存取不同位置的货物导致随机访问。 最后，总结时强调两种写入方式的设计选择是基于它们不同的用途和性能优化考虑，确保MySQL在事务处理和崩溃恢复上达到高效和可靠。</think>### 分步解析：MySQL 数据页刷盘（随机写）与 Redo Log 刷盘（顺序写）的本质区别 --- #### **一、核心结论** - **数据页刷盘（随机写）**：数据页在磁盘上存储位置不连续，修改时需要按实际物理位置写入，导致随机I/O。 - **Redo Log 刷盘（顺序写）**：Redo Log 以追加方式写入固定大小的文件，形成连续地址写入，天然支持顺序I/O。 - **本质原因**：两者的存储结构和用途不同，决定了写入方式的差异。 --- #### **二、底层机制对比** ##### **1. 数据页刷盘（随机写）** **核心流程**： 1. **修改发生**：事务修改数据时，先更新内存中的缓冲池（Buffer Pool）数据页。 2. **脏页标记**：修改后的数据页标记为“脏页”（Dirty Page）。 3. **刷盘触发**： - **后台线程周期性刷盘**（如每秒一次）。 - **缓冲池空间不足时强制刷盘**（LRU机制）。 4. **写入磁盘**：将脏页按实际物理位置写回表空间文件（`.ibd` 文件）。 **随机写的原因**： - **数据分布不连续**：数据页在表空间中的物理位置由主键、索引结构决定，修改后的脏页可能分布在磁盘的不同位置。 - **异步刷盘**：刷盘操作是批量且延迟的，无法保证写入顺序。 - **碎片化写入**：频繁的增删改操作导致表空间文件产生碎片，进一步加剧随机I/O。 ```text 示例：表空间文件（.ibd） +---------+---------+---------+ | 页1 (A) | 页2 (B) | 页3 (C) | --> 修改页1和页3后刷盘 +---------+---------+---------+ ↓ 磁盘写入：页1（位置0） → 页3（位置2） → 随机I/O ``` ##### **2. Redo Log 刷盘（顺序写）** **核心流程**： 1. **日志记录**：事务提交前，将修改操作按顺序写入 Redo Log Buffer。 2. **刷盘策略**： - **策略1（默认）**：事务提交时强制刷盘（`innodb_flush_log_at_trx_commit=1`）。 - **策略2**：每秒刷盘（`innodb_flush_log_at_trx_commit=0/2`）。 3. **写入磁盘**：Redo Log 以追加方式写入日志文件（`ib_logfile0`、`ib_logfile1`）。 **顺序写的原因**： - **固定文件结构**：Redo Log 文件是预先分配的环形文件，写入时始终追加到当前文件末尾。 - **物理连续写入**：日志条目按事务提交顺序连续写入，无地址跳跃。 - **崩溃恢复依赖**：顺序写保证日志的完整性，避免恢复时出现空洞。 ```text 示例：Redo Log 文件 +-------+-------+-------+-------+-------+ --> 始终追加写入 | Log1 | Log2 | Log3 | Log4 | ... | +-------+-------+-------+-------+-------+ 写入方向：→ 顺序追加 ``` --- #### **三、性能与设计权衡** | **维度** | **数据页刷盘（随机写）** | **Redo Log 刷盘（顺序写）** | |------------------|--------------------------------------------|-------------------------------------| | **写入速度** | 慢（HDD随机I/O吞吐量约100 IOPS） | 快（HDD顺序I/O吞吐量约200 MB/s） | | **可靠性** | 异步刷盘可能丢失未提交数据 | 事务提交时强制刷盘保证持久性 | | **设计目标** | 平衡内存与磁盘性能，减少频繁刷盘开销 | 最大化写入吞吐量，保障事务持久性 | | **优化手段** | 缓冲池（Buffer Pool）、Change Buffer | 组提交（Group Commit） | --- #### **四、关键问题解答** ##### **1. 为什么 Redo Log 不设计为随机写？** - **性能需求**：事务提交要求高吞吐量，顺序写速度是随机写的数百倍。 - **崩溃恢复**：顺序写保证日志连续性，恢复时无需跳跃读取。 ##### **2. 数据页能否改为顺序写？** - **不可行**：数据页的物理位置由索引结构（如B+树）决定，无法强制连续存储。 - **代价过高**：若强制按顺序存储，会破坏索引的高效查询特性。 ##### **3. Redo Log 如何避免写满？** - **Checkpoint 机制**：定期将 Redo Log 中的已提交修改刷盘到数据页，释放日志空间。 - **循环复用**：Redo Log 文件以环形结构复用，覆盖已刷盘的旧日志。 --- #### **五、总结** - **数据页随机写**：由数据存储的物理分布特性决定，是权衡查询性能与刷盘开销的结果。 - **Redo Log 顺序写**：为满足事务持久性与高吞吐量需求，利用磁盘顺序I/O优势。 - **设计哲学**：通过 Redo Log 的**顺序写**牺牲少量日志空间，换取事务提交的高性能；通过数据页的**随机写**容忍延迟刷盘，保障查询效率。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

打赏作者

Coderabo

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

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

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

打赏作者

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

抵扣说明：

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

余额充值