MySQL默认配置下数据真的不会丢吗——redo落盘的风险分层拆解

MySQL默认配置下数据真的不会丢吗——redo落盘的风险分层拆解

运维问过一次：把 innodb_flush_log_at_trx_commit 改成 2 能快多少。我说先别急着改——得先搞清楚默认值=1 到底防住了什么、没防住什么。改可以，但要知道自己放弃了哪一层保护。

文章目录

• MySQL默认配置下数据真的不会丢吗——redo落盘的风险分层拆解
• • 基础环境
  • 一、写入路径：一个事务提交到底发生了什么
  • • 一个重要的性能提醒
  • 二、分层拆解：每一层缓存可能丢什么
  • • 第一层：InnoDB Buffer Pool / Redo Buffer（数据库内存）
    • 第二层：操作系统 PageCache（内核缓存）
    • 第三层：磁盘板载写缓存（最容易被忽视的风险）
    • UPS 到底能防什么、不能防什么
  • 三、风险排序（按真实概率，从高到低）
  • 四、这套方案的优缺点
  • • 优点
    • 缺点
  • 五、落地建议
  • 一句话

基础环境

这篇讨论的前提是以下环境，不是所有场景都适用——先框住边界。

如果你是 flush_log_at_trx_commit=2 或其他 IO 模式，文中的安全边界不适用。

一、写入路径：一个事务提交到底发生了什么

事务提交时的数据流：

事务产生 redo 记录
│
▼
写入 InnoDB Redo Buffer（内存）
│
▼
拷贝到 OS PageCache（内核缓存，未落盘）
│
▼
调用 fsync() 阻塞等待
│
▼
磁盘控制器确认持久化成功
│
▼
commit 返回给客户端

redo 是环形文件追加写入，本质是逻辑顺序写——只有日志文件切换时才产生少量寻道。相比数据文件的随机 IO，顺序写的性能优势是数量级的。这就是 WAL 的核心价值：用廉价的顺序写替代昂贵的随机写。

但也正因为 commit 在等 fsync，瞬时吞吐量不会无限高——写入上限由磁盘的顺序写性能决定。OS PageCache 可以合并零散的 redo 写入，小幅优化 fsync 效率，但不能绕过磁盘物理上限。

一个重要的性能提醒

大量持续写入时，数据文件脏页在 OS 缓存中累积，由内核异步刷盘，本身不会阻塞业务写入。但有一个阈值陷阱：

# 查看当前脏页阈值
sysctl vm.dirty_ratio vm.dirty_background_ratio

当系统脏页总量触及 vm.dirty_ratio 阈值时，新的 write 调用会被内核阻塞直到脏页降到阈值以下。这时候你会看到周期性写入延迟抖动——不是数据库的问题，是 OS 脏页机制在刹车。

关键区分：想享受"缓存带来的极速写入"需要 innodb_flush_log_at_trx_commit=2（commit 只写到 PageCache 不等 fsync）。默认配置 =1 没有这种爆炸性能，换来的代价是事务持久化安全——这个取舍是本文讨论的前提。

二、分层拆解：每一层缓存可能丢什么

数据从内存到磁盘经过四层缓存，每层都有自己的丢失风险。

第一层：InnoDB Buffer Pool / Redo Buffer（数据库内存）

• redo 在 commit 阶段已经推送到 OS PageCache
• 事务成功前必须 fsync
• 单纯数据库进程崩溃（OOM Kill、MySQL crash），已提交的事务不会丢

第二层：操作系统 PageCache（内核缓存）

这一层是很多争论的焦点。风险场景：

但在默认参数 =1 下，commit 等待 fsync 完成才返回——redo 已经刷离 PageCache 落盘了。 所以内核崩溃不会导致已提交事务丢失。

但有一个容易忽略的细节：数据文件的脏页（非 redo）存在 PageCache 中，内核崩溃时这些脏页会丢。不过这不影响事务一致性——恢复时 InnoDB 用 redo 重放就能重建这些数据页。丢的是"还没刷盘的旧版本数据"，不是"已提交的事务"。

结论：默认参数下，OS PageCache 不会造成已提交事务丢失。丢失风险只出现在 flush_log_at_trx_commit=2 或 =0 时。

第三层：磁盘板载写缓存（最容易被忽视的风险）

这层风险知道的人不多，但它是整条链路里唯一的"无法用软件兜底"的环节。

普通 SSD / HDD（无断电保护 PLP）：

• 磁盘收到 IO 数据先进板载缓存，立即返回成功
• fsync 下发 FLUSH/FUA 指令要求强制刷入物理介质
• 理论上的逃逸窗口：固件 bug 或指令异常，导致 fsync 返回成功但数据仍在盘缓存中
• 此时如果硬盘硬件损坏、硬盘瞬时断电，这部分缓存数据丢失
• 概率极低，但物理上存在这个窗口

企业级 SSD（带 PLP 断电保护电容）：

• 外部停电时，电容足够把缓存数据写入闪存
• 仅硬盘内部硬件烧毁才会失效

UPS 到底能防什么、不能防什么

很多运维把 UPS 当成"数据安全"的同义词。拆开看：

UPS 和双市电只保护外部供电这一条线。服务器内部故障、硬盘自身问题，它们管不了。

三、风险排序（按真实概率，从高到低）

在当前架构（MySQL 默认参数 + 双市电 + UPS）下：

再次强调：只要保持 innodb_flush_log_at_trx_commit=1，内核崩溃不会导致已提交事务丢失。这个点跟 =2 有本质区别。

四、这套方案的优缺点

优点

• 遵循 InnoDB 标准安全基线，满足 ACID 持久化要求——互联网主流方案，不是野路子
• 充分利用 WAL 机制，用低成本顺序写承载事务提交，避免昂贵的随机 IO
• 数据文件依赖 OS 缓存异步刷盘，磁盘 IO 压力平滑
• 无需改动数据库默认参数，运维简单，不容易踩参数配置坑
• 磁盘写缓存可以合并 IO，优化 redo 顺序写入性能（机械硬盘场景尤其明显）

缺点

• Buffer Pool + OS PageCache 双重缓存，内存资源存在一定浪费
• 内核脏页参数配置不当时，大批量写入会出现周期性 IO 抖动
• 无 PLP 普通磁盘存在极小概率底层缓存丢失风险（概率低但非零）
• 相比 O_DIRECT 方案，数据库无法自主管控刷盘节奏，IO 调度权交给 Linux 内核

五、落地建议

# 降低脏页触发阈值，避免持续写入时周期性IO阻塞
sysctl -w vm.dirty_ratio=10
sysctl -w vm.dirty_background_ratio=5

一句话

在双市电 + UPS 供电、MySQL 默认参数下，这套方案是均衡稳妥的工业通用方案——靠 WAL 保证 redo 落盘、用顺序写获得不错性能，残留风险仅为极低概率的硬件级故障。绝大多数业务可以接受。

如果你要改成 flush_log_at_trx_commit=2，那就得自己承担 OS PageCache 丢失的风险——不是不能改，但得先知道改掉的是什么。