InnoDB redo log：WAL、checkpoint 与写满排查

一次线上故障复盘让我重新捡起了 redo log 这个老话题。当时那台机器的写入压力突然翻了几倍，QPS 没掉，但业务侧的更新延迟肉眼可见地变长，监控上磁盘 util 快到 100%，而 CPU 却很闲。翻了半天慢查询，一条都没抓到,最后在 InnoDB 的状态输出里看到 checkpoint 已经逼近日志末尾,日志空间快被写满了,后台刷脏根本追不上。问题不在 SQL,而在 redo log 的容量和刷盘节奏。这件事之后我把 redo log 的相关参数、内部结构、崩溃恢复路径重新捋了一遍,发现很多我以为是"常识"的地方其实经不起追问:为什么先写日志比直接写数据页快、日志写满之后到底是谁在等、双 1 配置下吞吐还有没有优化空间。

这篇内容就是那次复盘的完整沉淀。它不讲"redo log 是什么"这种教科书定义,而是从物理结构、刷盘策略、checkpoint 推进、线上排查几个角度,把 redo log 真正会咬人的地方拆开讲。适合已经会写 SQL、跑过线上库,但对 InnoDB 内部机制还停留在"背过八股"阶段的同学;也适合正在做容量规划、需要判断日志该开多大的后端和运维同学。看完你应该能自己算出日志该配多大,看到状态输出知道哪几个数字要盯,遇到"日志写满"的告警不慌。

1. 从一次断电事故反推 redo log 的真实职责

1.1 缓冲池里的脏页和那笔还不上的"债"

InnoDB 读写数据的最小单位是页,默认 16KB。所有读写都先经过 Buffer Pool,修改数据时改的是内存里的页,这个页就跟磁盘上的版本不一致了,业内叫脏页。脏页迟早要落盘,但"迟早"这两个字就是全部问题的来源——如果一笔事务提交后,脏页还在内存里没落盘,这时候机器断电,这笔已经告诉用户"成功"的修改就凭空消失了。

最朴素的想法是:那提交时就把脏页刷下去呗。问题是随机刷一个 16KB 的页,对磁盘来说是随机 IO,一次事务可能只改了页里 10 个字节,却要付出整页落盘的代价。一台机器上每秒几千笔事务,每笔都随机刷页,磁盘立刻被打穿。更麻烦的是,一个事务往往涉及多个页的修改,这些页在磁盘上物理位置分散,刷起来是无序的,顺序写和随机写的性能差距在机械盘上能到两个数量级,即使换成 SSD,随机写的放大效应和寿命损耗也不划算。

所以 InnoDB 换了个思路:提交时我不保证数据页落盘,我只保证"我改了什么"这件事被记下来,而且这个记录是顺序追加写的。等将来空闲了,再按记录把脏页刷下去。这个记录就是 redo log。它记的不是"某行数据现在是什么值",而是"某个表空间的某个页的某个偏移,从多少改成了多少",是纯粹的物理层面描述。因为只记增量,单条记录通常只有几十字节,顺序追加到文件末尾,一次 IO 就能攒下大量修改。

这里有个容易被忽略的点:redo log 保证的是已提交事务的修改不丢,不是"数据页立刻正确"。崩溃恢复时,InnoDB 先用 redo log 把可能没落盘的修改重放一遍(前滚),再用 undo 把没提交的事务回滚掉。redo 是"补做",undo 是"撤销",两者配合才还原出一致状态。很多人以为 redo 能恢复一切,其实它只负责已提交部分的前滚。

1.2 WAL:为什么"多写一份"反而更快

初学者最常问的一个问题是:本来就要写数据页,现在还要额外写一份日志,这不是多了一次写吗,怎么会快?这个疑问的答案藏在写的形态里。

写数据页是随机的、离散的、粒度大的;写 redo log 是顺序的、连续的、粒度小的。顺序追加几乎没有寻道成本,而且 InnoDB 在刷 redo 的时候还会做组提交,把多个事务的日志攒在一起,一次 fsync 落一批。这就好比记账:每笔交易都去仓库里搬一次货、清点一次库存,那是随机大 IO;而先在流水账本上按顺序记一行"某货架某位置从 3 件改成 5 件",等晚上再统一盘点,流水账写字快、连续、还不用来回跑。花在流水账上的额外成本,远小于省下来的随机盘点成本。

还有一个更关键的收益:事务的响应时间变得可预期。如果提交时必须把涉及的所有数据页都刷到磁盘,那事务的耗时取决于这次改了多少页、这些页在磁盘上散得多开,抖动会非常大。而只写一条顺序日志,耗时基本恒定,只有 fsync 那一下的延迟。所以 WAL(Write-Ahead Logging)不是"多写一份"的妥协,它是把随机写转成顺序写、把不可控延迟转成可控延迟的核心设计。

我个人体会是,理解 WAL 的价值,关键要建立"日志是数据页的欠条"这个心智模型。事务提交时欠条先立好,数据页什么时候还都行,只要欠条在,债权人(崩溃恢复)就不怕。这也解释了为什么 redo log 必须先于数据页落盘——欠条都还没写,你先把货搬了,出了事谁也说不清。InnoDB 里对应的规则叫 write-ahead:刷脏页之前,必须保证这个页对应的 redo 已经持久化,否则不允许刷。这条规则是整套机制的地基。

1.3 redo log 和 binlog 的边界,别再混着背了

这两个日志几乎每次面试都会被拉出来对比,但很多人背的是"一个物理一个逻辑",背完还是不知道什么时候该看哪个。我换个说法:redo log 是引擎内部的施工记录,binlog 是数据库对外的成交流水。

redo log 只有 InnoDB 有,MyISAM 没有,因为它属于存储引擎层。它记录的是页级别的物理变更,内容是二进制,人看不懂,只能由 InnoDB 自己重放。它的生命周期很短,写完、对应的脏页刷盘、checkpoint 推过去之后,这段空间就被覆盖了,是循环使用的。binlog 属于 Server 层,所有引擎共用,记录的是逻辑操作( STATEMENT 格式记 SQL,ROW 格式记行变更),文本或半文本,人可以解析,主要用于主从复制和数据归档,是追加写、不会循环覆盖的。

因为两者的职责和生命周期完全不同,所以它们必须协同才能保证主从一致。这就是常说的两阶段提交:事务提交时,InnoDB 先写 redo 并标记为 prepare 状态,然后 Server 层写 binlog,binlog 写成功后再把 redo 标记为 commit。崩溃恢复时,如果发现 redo 里是 prepare 状态,就去比对 binlog 里有没有对应事务:有就提交,没有就回滚。这个设计的目的是让两份日志的"成与不成"永远一致,不会出现主库有、从库没有的裂缝。

提醒一句:排查"主从数据不一致"和排查"实例崩溃后数据异常",看的完全是两套东西。前者优先看 binlog 和复制位点,后者才看 redo。方向搞反了会浪费大量时间。

2. ib_logfile 里的物理世界:块、LSN 与记录格式

2.1 日志文件组的循环写与 8.0.30 的目录改造

早期版本的 redo log 表现为数据目录下的一组文件,名字是ib_logfile0、ib_logfile1……,数量由innodb_log_files_in_group控制,单个大小由innodb_log_file_size控制,总容量是两者相乘。这组文件在逻辑上被视为一个环:写到最后一个文件的末尾,就绕回第一个文件的开头继续写,前提是绕回去的那部分空间已经被 checkpoint 释放了。这个"环"的概念非常关键,几乎所有"日志写满"的问题都源于环的周长不够,或者消费者(checkpoint)跑得太慢。

这种按文件数配置的方式有个实际痛点:改容量必须停机、删文件、重启,线上操作风险高。从 8.0.30 开始,官方把这块重做了,数据目录下多了#innodb_redo目录,里面是若干固定大小的文件(默认每个 32MB),总容量由innodb_redo_log_capacity这一个参数控制,支持在线动态调整。旧的innodb_log_file_size等参数被标记为废弃,虽然还能用,但实际会被换算成容量值。

-- 8.0.30 之后推荐这么设,支持在线改 SET GLOBAL innodb_redo_log_capacity = 4294967296; -- 4GB -- 查看当前实际的 redo 文件分布 SELECT * FROM performance_schema.innodb_redo_log_files;

这个改造对运维的意义不小:以前扩容要挑维护窗口,现在直接一条SET GLOBAL就生效,InnoDB 会在后台新增文件、逐步调整,业务基本无感。我在一个写入量波动很大的系统上就吃过亏,老版本因为容量给得保守,业务高峰固定踩日志写满,只能排窗口重启改参数,后来迁到新版本直接在线拉大,这个问题就彻底消失了。

2.2 512 字节的日志块与 LSN 的编码方式

redo log 文件内部不是裸着堆记录的,而是按512 字节划分成一个个日志块(log block)。为什么是 512?这和磁盘扇区大小对齐,保证单块写入是原子的,不会出现写了一半的撕裂块。每个块由三部分组成:12 字节的块头、最多 496 字节的块体(body)、4 字节的块尾校验。

块头里最值得关注的几个字段:

• 块序号,标识这个块在整个日志空间里的位置,用于校验顺序。
• 本块已用数据长度,告诉你块体里还有多少有效字节。
• 块内第一个记录组的起始偏移,用于崩溃恢复时快速定位到完整记录边界。
• checkpoint 序号,辅助判断这个块是否已经可以被覆盖。

一个 redo 记录可能跨块,甚至跨文件。为了处理跨块,InnoDB 允许一个块只存部分记录,剩下的接着放在下一个块。这就是为什么恢复时要先靠块头和块尾校验,确认这个块是完整写入的;如果块尾校验不通过,说明这个块写到一半断电了,恢复就停在上一块的末尾,后面的内容全部丢弃。

再说LSN(Log Sequence Number),它是 redo log 的"全局字节偏移量",一个单调递增的 64 位整数,起点不是 0,而是一个基准值。LSN 的逻辑构成是"文件编号 + 文件内偏移",高 32 位是第几个日志文件,低 32 位是文件内的字节偏移。理解这个编码方式很重要,因为你在状态输出里看到的很多数字都是 LSN,它们之间的差值直接对应"还有多少字节没处理"。

-- 看当前 LSN 相关的一组数值 SHOW ENGINE INNODB STATUS\G -- 输出里的 LOG 段大致长这样: -- Log sequence number 12345678901 -- Log flushed up to 12345678000 -- Pages flushed up to 12345000000 -- Last checkpoint at 12344999000

这四个数字的差值是排查的核心抓手,后面第 5 节会详细拆。

2.3 一条 redo 记录里到底存了什么

redo 记录的格式按类型区分,但通用头部相对稳定:记录类型、所在表空间的 ID、页号、页内偏移,然后才是具体变更内容。按变更类型,常见的有:

• 单字节/双字节/四字节/八字节写:对应页内某个小字段的修改,比如更新一行里某个整型列的值,记录只带旧值到新值的差异。
• 字符串写:变长字段的修改,带上要写入的字节内容。
• 记录插入/删除:对应 B+ 树叶子节点的插入删除,带上主键和必要的索引信息。
• 页分配/页初始化:新页加入时的结构初始化动作。
• 压缩页相关:压缩表特有的操作类型。

一个关键概念是MTR(Mini Transaction),翻译成"迷你事务"。一组必须原子完成的操作会被打包成一个 MTR,比如"在 B+ 树里插入一条记录"可能涉及页内挪动、页分裂、目录项更新等十几个动作,这些动作的 redo 记录被打包成一个组,组内有一个原子边界标记。恢复时以 MTR 为单位重放,保证要么全做要么全不做,不会停在半个 B+ 树操作上留下结构性损坏。这个设计思路和数据库事务是一个道理,只是粒度下沉到了页内操作。

理解了记录格式,你就明白为什么 redo log不能跨版本随便乱读:记录类型和格式跟版本强相关,8.0 的 redo 文件不可能被 5.7 解析。所以做版本升级、尤其是跨大版本升级时,官方要求干净关闭(shutdown 而不是 kill),让所有脏页刷完、checkpoint 推到底,重启后不需要重放老格式日志,这样最安全。我见过一次粗暴 kill 之后直接换版本的案例,启动时重放失败,最后只能从备份恢复,代价很大。

3. innodb_flush_log_at_trx_commit 的三种取值,差的不只是安全性

3.1 0、1、2 三档分别刷到了哪一层

这个参数几乎是 MySQL 调优里被讨论最多的一个,但很多人只记住"1 最安全、0 最快",说不出中间到底差在哪一层。把它拆成三层来看就清楚了:应用内存(InnoDB 的 log buffer)、操作系统页缓存(OS cache)、磁盘持久介质。

• = 0:事务提交时,redo 记录还留在 InnoDB 的 log buffer 里,不往 OS 写。InnoDB 有一个后台线程每秒把 buffer 刷到 OS 缓存并 fsync 一次。所以极端情况下可能丢 1 秒内的事务,而且丢的是"连 OS 缓存都没到"的部分。
• = 1:事务提交时,立刻把 redo 写到 OS 缓存并fsync 到磁盘才返回成功。这是唯一能保证"提交成功就一定不丢"的档位,代价是每次提交至少一次 fsync。
• = 2:事务提交时,把 redo 写到 OS 缓存就返回,不 fsync。由后台每秒 fsync 一次。所以正常情况下不丢(只要操作系统不崩),但如果整机断电或操作系统崩溃,OS 缓存里的内容会丢,可能丢 1 秒。

这里有个很多人搞混的细节:= 0和= 2在"每秒刷一次"上看起来一样,但差别在于= 0时数据还在 InnoDB 自己的用户态 buffer 里,连内核都没交给;= 2时已经交给内核了,只是没落盘。所以= 2在数据库进程崩溃(比如被 kill)的情况下是不丢的,因为数据已经在 OS 手里,进程死了内核还在;而= 0会丢,因为 buffer 在进程内存里,进程一死就没了。这个区别在实际运维里挺重要——如果你的环境是容器,容器重启(不是整机断电)时,= 2的安全性明显好于= 0。

我个人的建议很直接:只要这笔数据丢了需要人工补、需要对账、需要向用户解释,就老老实实设 1。省下来的那点 fsync 开销,可以用硬件和批量提交补回来,不值得拿数据一致性去换。

3.2 组提交如何把 fsync 的成本摊薄

看到= 1每次提交都 fsync,很多人第一反应是"那并发一高不就废了"。实际上 InnoDB 有一个非常精巧的机制叫组提交(group commit),它把并发的多个事务的 fsync 合并成一次。

原理不复杂:多个事务同时提交时,它们各自把 redo 写进 log buffer,然后排到一个队列上。队列里的第一个线程(leader)负责执行一次 fsync,把这一批全部落盘,然后唤醒后面所有等待的线程。这样 100 个并发事务可能只花 1 次 fsync 的时间,而不是 100 次。并发越高,摊销效果越明显;并发很低时,组提交没得组,退化成每笔一次 fsync,这时候单笔延迟就是磁盘 fsync 的真实延迟。

MySQL 5.7 之后还对组提交做了三段式拆分:flush 阶段(把 log buffer 写到 OS 缓存)、sync 阶段(fsync)、commit 阶段(引擎层提交)。三段各自可以组队,进一步提升了并发度。到了 8.0,binlog 的组提交也做了类似优化,配合两阶段提交,整体吞吐比 5.6 时代好了一大截。

这也解释了一个反直觉的现象:同一个库,单线程压测时 QPS 可能只有几百,并发拉到 64 之后 QPS 反而涨到几千。不是因为 CPU 变强了,是因为 fsync 被摊销了。所以评估= 1的性能影响,一定要用接近真实并发度的压测,单线程测出来的数字没有参考价值。另外一个实操经验:如果磁盘本身的 fsync 延迟就很高(比如用了没有掉电保护的廉价 SSD 或者网络存储),组提交也救不了你,因为一次 fsync 就要几十毫秒,这时候该换硬件而不是调参数。

3.3 双 1 配置下还能从哪儿抠性能

"双 1"指的是innodb_flush_log_at_trx_commit=1加上sync_binlog=1,这是金融级场景的标配,保证提交即持久。在这个前提下想提吞吐,能动的其实是这几个地方。

第一是批量提交。业务侧把多条 INSERT 合成一条多值 INSERT,或者把一批更新放进一个事务里。这样 N 条记录只触发一次组提交、一次 fsync,收益非常直接。我做过对比,同样写 1 万行,单条提交和 100 条一组的批量提交,耗时能差一个数量级。

第二是降低 binlog 的同步频率需要谨慎。sync_binlog=1是最安全的,但也有=N的选项,表示每 N 次提交才 fsync 一次 binlog。这个值调大会有丢失风险,一般不建议在主库上动,在主从架构里如果从库可重建、主库有半同步兜底,可以评估。半同步复制(rpl_semi_sync_source_...)其实就是用"至少一个从库确认收到"来换取主库上更激进的刷盘策略,这是一种用架构换性能的思路。

第三是关注 fsync 的实际延迟。可以用iostat -x 1看fdatasync/s和设备 await,如果 await 经常超过 10ms,说明存储层已经是瓶颈,这时候调任何参数都是隔靴搔痒。有条件的机器上配一块带掉电保护的阵列卡或者企业级 NVMe,fsync 延迟能压到亚毫秒级,双 1 的吞吐会有质变。

第四是减少不必要的日志量。大事务会产生海量 redo,长事务会长时间占住 undo 和旧日志空间,让 checkpoint 推不动。把大事务拆小、避免全表 UPDATE、避免无索引的批量更新,这些看似和 redo 无关的操作,实际上直接决定了日志空间的周转效率。

4. checkpoint 推不动的时候,日志空间就开始告急

4.1 checkpoint 到底在推进什么

checkpoint 这个概念被讲得很玄,其实一句话:它是一个"截至这里,之前的脏页都已经落盘了"的水位线。水位线之前的日志空间可以被安全覆盖,水位线之后的还得留着,因为对应的脏页可能还没刷。

InnoDB 的状态输出里Last checkpoint at就是这条水位线。日志的"环"要绕回开头写,前提是开头那段已经被水位线越过。如果写入速度一直快于水位线推进速度,环很快就被填满,写到末尾发现开头还没释放,就只能停下来等——这就是"日志写满"的本质。

水位线怎么推进?主要有几个触发点。一是后台刷脏线程周期性工作,把脏页按一定速率刷下去,刷完之后水位线自然前进。二是日志空间使用率达到阈值时触发更激进的刷脏。三是正常关闭时做一次 full checkpoint,把所有脏页刷干净。四是LRU 淘汰时顺带刷脏,比如 Buffer Pool 不够用,要淘汰一个脏页,得先把它刷下去。

这里有个关键的耦合关系:checkpoint 推进的速度,本质上受限于刷脏的速度,而刷脏的速度受限于磁盘的随机写能力和脏页的分布。如果脏页在磁盘上非常分散,刷起来慢,水位线就推得慢,日志空间周转就慢。所以你会看到一个现象:同样的日志容量,随机写入压力大的库比顺序写入压力大的库更容易撞日志写满。

4.2 日志写满时的真实表现:不是报错,是卡住

很多人以为日志满了会报一个明确的错。实际线上更多是所有写入线程集体卡住,表现为业务侧延迟飙升、连接数堆积,但错误日志里干干净净。因为 InnoDB 的处理方式是:写日志的线程发现空间不够,进入等待,等 checkpoint 推进腾出空间后再继续。它不会让事务失败,只会让它等。

这个等待在 8.0.13 之前有个计数器innodb_log_waits,可以看累计等待次数。之后这个指标被移除,改成了 performance_schema 里的一些等待事件,需要从events_waits_summary_global_by_event_name里找,或者观察innodb_log_write_requests和实际写入量的关系。

这个"卡住而不报错"的特性非常坑人。业务同学看到的是接口超时,研发同学第一反应是查慢 SQL,结果慢日志里一条都没有,因为 SQL 本身执行得很快,时间全耗在等日志空间上了。我在前面说的那次故障里就是这么被误导的,查了两小时 SQL 才发现方向错了。

判断是不是日志空间问题,最快的办法就是看状态输出里Log sequence number和Last checkpoint at的差值,再和总容量比。如果差值已经接近总容量,基本可以确诊。另一个辅助信号是磁盘指标:如果发现写入 IOPS 突然升高但业务 QPS 没涨,说明后台在拼命刷脏救火。

4.3 innodb_redo_log_capacity 该配多大:一个可算的公式

容量配多少合适,是可以算出来的,不用拍脑袋。核心思路是:日志空间必须能容纳"在 checkpoint 最慢的情况下,系统在这段时间内产生的所有 redo"。

估算公式:

所需容量 ≈ 峰值 redo 产生速率 (MB/s) × 可容忍的最长刷脏滞后时间 (s) × 安全系数

其中峰值速率可以在业务高峰时采样:连续两次读Log sequence number,差值除以时间间隔,就是这段时间的平均产生速率(注意这里包含了所有写入,不是只有提交)。可容忍的最长刷脏滞后时间,取决于你的磁盘能多快把脏页刷完,一般取 30 到 60 秒比较稳妥。安全系数取 1.5 到 2。

举个具体的例子。假设高峰时采样到 redo 产生速率是 20 MB/s,磁盘刷脏能在一个周期内跟上,取最长滞后 60 秒,安全系数 1.5,那么至少需要20 × 60 × 1.5 = 1800 MB,也就是大约 2GB。再考虑业务会增长、批处理任务会有尖峰,给到 4GB 会更从容。

官方文档里还有一条经验法则:日志容量应该足够容纳一到两小时的写入量。这个说法适合写入平稳的系统,但对有周期性尖峰(比如凌晨跑批)的系统就偏保守或者偏激进,我更倾向用上面的采样公式,因为它是从你自己的负载里量出来的。

-- 采样 redo 产生速率的简便方法:间隔 10 秒读两次 SHOW ENGINE INNODB STATUS\G -- 记下 Log sequence number -- 等 10 秒 SHOW ENGINE INNODB STATUS\G -- 再记一次,差值 / 10 秒 就是速率

配大一点有代价吗?几乎没有。唯一的成本是磁盘空间,以及崩溃恢复时要重放更多日志,启动会慢一些。相比之下,配小了导致的写入卡顿是实打实的业务损失。所以我的原则是:宁可大,不要小。现在 4GB 到 8GB 是很常见的配置,写入重的系统给到 16GB 也不夸张。

5. 状态输出里的那四个数字,到底该怎么读

5.1 拆解 LSN 差值对应的四种状态

回到第 2 节提到的那四个数字,现在可以完整解读了。它们都是 LSN,单位是字节,彼此之间的差值代表了系统中四个不同环节的进度差:

最有诊断价值的两个差值:

第一个差值:Log sequence number - Log flushed up to。这是还没落盘的日志量。如果这个值持续偏大(比如长期超过几十 MB),说明日志写入跟不上产生速度,可能是 fsync 太慢或者写压力太大。正常情况下这个值应该很小,因为组提交会很快把它消化掉。

第二个差值:Log sequence number - Last checkpoint at。这是已使用的日志空间。把它和总容量做比值,就得到使用率。超过 75% 就该警惕,超过 90% 基本就是在悬崖边上。

我用一个模拟的例子说明怎么读。假设总容量 4GB,状态输出是:

Log sequence number 5368709120000 Log flushed up to 5368708900000 Pages flushed up to 5368600000000 Last checkpoint at 5368599000000

算一下:最新 LSN 减水位线约 110MB,占 4GB 的 2.7%,非常健康。但Log sequence number - Log flushed up to约 220MB,这个就偏大了,说明有大量日志积压在没 fsync 的状态。这可能是瞬间的采样点,也可能是innodb_flush_log_at_trx_commit设成了 0 或 2,或者后台刷盘线程被阻塞了。这种"空间健康但刷盘滞后"的组合,往往意味着马上要出问题——一旦机器断电,丢的可不止一秒。

5.2 三类典型异常对应的根因方向

我把实际遇到过的异常归成三类,基本能覆盖大多数场景。

类型一:水位线长期不动,使用率缓慢爬升。表现为Last checkpoint at几分钟都不变,而 LSN 一直在涨。根因通常是刷脏跟不上:可能是磁盘随机写能力不足,可能是脏页太多导致刷脏队列积压,也可能是 Buffer Pool 太小、脏页比例过高。排查方向是看Innodb_buffer_pool_pages_dirty的比例,以及磁盘的写入 await。这种情况下的应急手段是临时调大innodb_io_capacity和innodb_io_capacity_max,让后台刷脏更激进,但这只是缓解,根子还在硬件或容量上。

类型二:使用率瞬间冲高再回落,周期性出现。这是典型的批处理尖峰。某个定时任务一次性更新大量数据,瞬间产生海量 redo,水位线来不及推。根因是业务侧的批量操作设计不合理。解法是拆批,比如每 1000 行提交一次,中间 sleep 一下给刷脏留出时间。这种问题靠加容量只能推迟爆发,不能根治,因为尖峰的绝对量没有变。

类型三:一切正常,但崩溃恢复时间越来越长。这说明日志容量配得过大而 checkpoint 推得不够勤,导致重启时要重放的日志太多。这种情况反而要适度缩小容量,或者调整刷脏频率,让水位线推进得更积极。恢复时间过长在云环境下尤其危险,因为实例重启有超时限制,重放超时会被直接判定为启动失败。

补充一个实操细节:观察这些指标不要只看一个时间点,至少连续采样 5 到 10 分钟,看趋势。单次采样很容易被瞬间的组提交或者刷脏动作误导。

5.3 在线扩容的完整操作与验证

如果确诊是容量不够,8.0.30 之后的扩容步骤很简单,但每一步都要验证,不能设完就走。

第一步,记录扩容前的基线:当前容量、使用率、redo 产生速率。

-- 查看当前配置值和实际文件情况 SHOW VARIABLES LIKE 'innodb_redo_log_capacity'; SELECT FILE_NAME, START_LSN, END_LSN, SIZE_IN_BYTES FROM performance_schema.innodb_redo_log_files;

第二步,动态调整。这是一个 online 操作,InnoDB 会创建新文件、逐步迁移,期间不影响业务写入。

SET GLOBAL innodb_redo_log_capacity = 8589934592; -- 调到 8GB

第三步,验证生效。注意SET GLOBAL只影响运行时,重启后会回到配置文件的值,所以必须同步修改配置文件里的innodb_redo_log_capacity,否则下次重启又变回去,这个坑我踩过一次,重启后容量悄悄缩水,过了两周又出问题。

# my.cnf 中持久化 [mysqld] innodb_redo_log_capacity = 8G

第四步,观察一段时间,确认使用率峰值明显下降,且Log sequence number - Log flushed up to没有异常放大。扩容本身不会让刷脏变快,只是给了更大的缓冲,如果刷脏能力本身是瓶颈,扩容只能推迟问题,还得配合调整innodb_io_capacity。

老版本(8.0.30 之前)的扩容就没这么优雅了:需要改innodb_log_file_size,然后干净关闭实例、确保正常 shutdown 完成 checkpoint、再启动。绝对不能 kill -9,否则启动时重放会遇到文件大小不匹配的问题,严重时只能从备份恢复。这一步我在早期版本上做过好几次,每次都提心吊胆,现在有了在线扩容真是省心太多。

6. 8.0 对 redo 写路径的重构,以及它对业务的实际影响

6.1 从一把大锁到无锁环形缓冲

5.7 时代的 redo 写入有个明显的性能天花板:所有写 redo 的线程要争抢同一把锁( log buffer 的 mutex),写入位置也是串行推进的。并发一高,锁竞争就成了瓶颈,CPU 花在等锁上的时间比干活还多。这也是为什么 5.7 在高并发写入场景下,即使硬件很好,吞吐也上不去。

8.0 做了一次比较大的改造,核心思路是把"写日志"这件事拆成几个专职线程,并用一种无锁的环形缓冲来协调进度。具体来说,用户线程把自己产生的日志写进一个共享的 link buffer,只做位置预留,不做实际 IO;真正把日志搬进 log buffer、刷到 OS、fsync 到磁盘的,分别是 log_writer、log_flusher 这些后台线程。用户线程写完就可以返回,不用等 IO。

这个设计带来的直接效果是:写日志的并发度大幅提升,锁竞争基本消失;而且因为 IO 是批量做的,组提交的效率更高。官方给的基准数据是在高并发写入场景下有数倍的提升,具体数字取决于硬件,但方向是明确的。

-- 8.0 里可以通过线程列表看到这些专职线程 SELECT NAME, TYPE FROM performance_schema.threads WHERE NAME LIKE '%log%'; -- 会看到 log_writer、log_flusher、log_write_notifier、log_flush_notifier 等

6.2 这些改动对日常运维意味着什么

这些底层改动,对普通业务开发来说是透明的,但对运维和容量规划有几个实际影响,值得提前知道。

第一,高并发下的吞吐表现变了。如果你从 5.7 迁到 8.0,同样的硬件和参数,写入吞吐大概率会提升,但单线程延迟可能没有明显变化甚至略有上升,因为路径变长了(多了线程间协调)。所以压测一定要用真实并发模型,不能只看单线程数字。有些团队迁移后发现"高峰期更顺了但单笔更慢了",就是这个问题。

第二,监控指标的语义有微调。innodb_log_waits在 8.0.13 之后被移除,如果你的监控体系还依赖这个指标告警,迁移后会静默失效——这比指标数值变化危险得多,因为你会以为"没有等待",实际上是"没在监控"。迁移前一定要把这类废弃指标的清单过一遍,用新的 performance_schema 事件替代。

第三,参数体系的变化。innodb_log_file_size、innodb_log_files_in_group这类参数在 8.0.30 后被innodb_redo_log_capacity取代,虽然还有兼容处理,但两套参数同时配容易互相打架。我建议迁移后统一改成一个容量参数,把老的删掉,避免出现"配置文件里写着 1GB,实际跑着 4GB"这种莫名其妙的情况。

第四,崩溃恢复的路径也优化了。8.0 在恢复阶段能并行处理一些步骤,大实例的恢复时间比 5.7 短。但要注意,如果日志容量配得特别大(比如 32GB 以上),恢复时间仍然会很长,因为要重放的内容总量摆在那里。云上部署时,一定把恢复时间纳入容量决策,别只顾着避免写满。

最后分享一个我自己的习惯:每次做容量规划,我都会在测试环境模拟一次"断电"——用kill -9杀掉数据库进程(注意只在测试环境做,生产环境千万别这么玩),然后记录重启到可用的耗时,以及恢复过程中的日志输出。这个演练能暴露很多纸面上看不出来的问题,比如重放卡在某个大事务上、或者恢复时间超过了编排系统的健康检查超时。演练过几次之后,你对这套机制的信心会完全不一样,遇到真实故障时才不会手忙脚乱。