第36章：Redo、Checkpoint 与崩溃恢复源码剖析

1. 项目背景业务场景某金融系统的核心交易库在一次异常宕机后启动时错误日志中显示 “InnoDB: Page [page id: space123, page number456] log sequence number 789012345 is in the future!”——崩溃恢复失败——mysqld 无法启动。DBA 尝试了innodb_force_recovery1到 3 都没有成功——最后只能接受数据全部清空重来。事后分析发现——双写缓冲Doublewrite Buffer中的某个页已经损坏——但在崩溃前被写入了错误的 LSN——导致恢复时 redo 重放到这个页时检测到 LSN 不一致——中断了整个恢复过程。痛点redo log 和 Checkpoint 是 InnoDB 持久性的根基——从源码层面理解它们——才能真正掌握数据安全LSN 不一致即灾难每个数据页的头部都有 LSN 标记——崩溃恢复时对比页头 LSN 和 redo LSN——如果不一致——恢复过程可能需要数小时甚至永久失败。Checkpoint 推进慢拖累一切脏页太多 → Checkpoint Age 逼近 redo 总大小 → 激烈刷新 → 写入阻塞。双写缓冲的微妙它同时是保护天使和性能杀手——在 SSD 上开启后写入放大 2 倍——但不开就有 torn page 风险。log writer 线程的行为不透明redo log 从 log buffer 到磁盘的过程由多个线程协作——理解它们的行为才能调优刷盘参数。本章从源码层面解剖 redo log 的写入链路、Checkpoint 的推进机制和崩溃恢复的三阶段——让你真正理解 InnoDB 的持久性保障。2. 项目设计【场景小胖的虚拟机强制关机后——MySQL 启动报错——LSN 不一致】小胖“大师为什么 MySQL 崩溃后自己恢复不了上次我们模拟 kill -9 不是都恢复成功了吗”大师“Kill -9 走的是正常的崩溃恢复——redo log 是完整的——InnoDB 能够重放。但你的这次是硬件虚拟机的强制关机——在 InnoDB 正在写数据页时被中断——页面只写了一半——这叫做 torn page撕裂页。这个半页上记录的 LSN 和 redo log 中的 LSN 不匹配——恢复时就报错了。”小白“那双写缓冲Doublewrite Buffer是怎么防止 torn page 的”大师“双写缓冲的原理很简单——在写入真正的数据页之前先把这些脏页顺序写入一个小型共享表空间ibdata1 中的 doublewrite segment中。这个顺序写很快——而且如果写了一半掉电——要么全写成功、要么没写成功因为顺序写。等这个双写区写成功后——再随机写入到真正的数据页位置。如果恢复时发现某个数据页的校验和不匹配torn page——InnoDB 就从双写区中找到这个页的完整副本——覆盖回真正的位置。”技术映射Doublewrite Buffer 脏页在写回真正位置之前——先顺序写入双写区。防止 torn page——是 InnoDB 在不支持原子页写入的存储设备上的关键安全保障。3. 项目实战3.1 环境准备# 确认相关源码目录ls~/mysql-src/storage/innobase/log/ls~/mysql-src/storage/innobase/buf/buf0dblwr.ccls~/mysql-src/storage/innobase/buf/buf0flu.cc# 源码中的关键文件# log/log0log.cc — redo log 核心管理log_t 结构体# log/log0write.cc — redo log 写入线程# log/log0recv.cc — 崩溃恢复# buf/buf0flu.cc — 脏页刷新Checkpoint 推进# buf/buf0dblwr.cc — 双写缓冲# os/os0file.cc — 文件 IOO_DIRECT / O_SYNC3.2 分步实现步骤一redo log 写入链路源码——从 log buffer 到磁盘// 文件storage/innobase/include/log0log.h// log_t 是 redo log 的核心结构体structlog_t{// 内存缓冲区 byte*buf;// redo log bufferinnodb_log_buffer_sizelsn_t buf_size;// buffer 大小// LSN 追踪 lsn_t lsn;// 当前已写入 log buffer 的最大 LSNlsn_t write_lsn;// 已写入 OS page cache 的 LSNlsn_t flushed_to_disk_lsn;// 已刷到磁盘的 LSN真正的持久化点lsn_t available_for_checkpoint_lsn;// 可用于推进 checkpoint 的 LSN// 刷盘策略 ulong write_ahead_buf_size;// 预写缓冲区boolwriter_threads_active;// 写线程是否活跃};// 文件storage/innobase/log/log0write.cc// log writer 线程——负责将 log buffer 刷到磁盘voidlog_writer(log_t*log_ptr){while(true){// 1. 等待有新的 redo 需要写入os_event_wait(log.writer_event);// 2. 把 log buffer 中 write_lsn 到 lsn 之间的数据写入 OS page cachelsn_t ready_lsnlog_buffer_ready_for_write_lsn(log);// → write() 系统调用 → OS page cache// 3. 更新 write_lsnlog.write_lsnready_lsn;// 4. 通知 flusher 线程——有新数据可 fsyncos_event_set(log.flusher_event);}}// log flusher 线程——负责 fsyncvoidlog_flusher(log_t*log_ptr){while(true){os_event_wait(log.flusher_event);// 调用 fsync() 将 OS cache 刷入磁盘// 根据 innodb_flush_log_at_trx_commit:// 1 每次 commit 后 fsync// 2 每次 commit 写 OS cache每秒 fsync// 0 每秒写 log buffer 到 OS cache 并 fsyncos_file_flush(log.flush_file);log.flushed_to_disk_lsnlog.write_lsn;}}-- 步骤目标观察当前 redo log 写入的实时状态-- 查看 LSN 推进情况两次采样可计算速率SHOWENGINEINNODBSTATUS\G-- LOG 段-- Log sequence number 1234567890123-- Log flushed up to 1234567890000-- Pages flushed up to 1234500000000-- Last checkpoint at 1234400000000-- 计算-- redo 生成速率 ΔLog sequence number / Δt两次查询间隔-- 未刷盘的 redo Log sequence number - Log flushed up to-- Checkpoint Age Log sequence number - Last checkpoint at步骤二Checkpoint 推进机制——脏页刷新策略// 文件storage/innobase/buf/buf0flu.cc// 脏页刷新——推进 Checkpoint 的核心逻辑voidbuf_flush_list_space_check(buf_pool_t*buf_pool){// 检查是否需要刷新脏页ulint n_flush0;// 条件 1脏页比例超过 innodb_max_dirty_pages_pct_lwmif(buf_get_modified_ratio_pct(buf_pool)srv_max_buf_pool_modified_pct){n_flush(srv_max_io_capacity*PCT_IO(100))/100;// 启动激烈刷新——用最大 IO 能力刷脏页}// 条件 2Checkpoint Age 太大redo 不够用lsn_t checkpoint_agelog_get_lsn(log)-log.last_checkpoint_lsn;if(checkpoint_agelog.max_checkpoint_age){n_flushsrv_max_io_capacity;// 必须立即刷脏页推进 Checkpoint——否则 redo 可能循环覆盖}// 从 Flush ListLRU 链表中脏页组成的子链表的尾部开始刷// 靠近头部的页是旧脏页需要优先刷——靠近尾部的页是新脏页buf_flush_list(n_flush,buf_pool);}// Checkpoint 的推进voidlog_checkpoint_low(log_t*log){// 找到 Flush List 中最老的脏页的 LSNlsn_t oldest_lsnbuf_pool_get_oldest_modification();// 只有这个 LSN 之前的所有脏页都刷到磁盘后——Checkpoint 才能推进log.last_checkpoint_lsnoldest_lsn;// 将 Checkpoint LSN 写入 redo log 文件头——崩溃恢复时从这里开始log_files_write_checkpoint(log);}# 步骤目标观察 Checkpoint Age 和脏页比例随时间的变化watch-n2mysql -uroot -pRoot123 -e SHOW ENGINE INNODB STATUS\G 2/dev/null | grep -E Modified db pages|Log sequence|Last checkpoint|Pending log步骤三崩溃恢复三阶段的源码追踪// 文件storage/innobase/log/log0recv.cc// 崩溃恢复入口函数dberr_trecv_recovery_from_checkpoint_start(log_t*log,lsn_t flush_lsn){// 阶段 1Analysis分析// 从最近一次 Checkpoint 开始——扫描 redo log 中的所有记录// 找出哪些数据页的修改没有刷到磁盘recv_sys.recover();// → 建立 recovery hash tablepage_id → { 需要该页的 redo 记录列表 }// 阶段 2Redo重做// 将所有未刷盘的脏页按照 redo log 重做recv_apply_hashed_log_recs(TRUE);// → 顺序读取 recovery hash table 中的页// → 对每个页依次应用所有相关的 redo 记录// → 数据页恢复到崩溃前的最新状态// 阶段 3Undo回滚// 找出崩溃时未提交的事务——通过 undo log 回滚trx_rollback_or_clean_all_recovered();// → 扫描 undo 表空间——找未提交事务// → 逐一执行反向操作——撤销未提交的修改returnDB_SUCCESS;}-- 验证清单-- 1. 确认 redo 日志文件存在-- ls -lh /var/lib/mysql/#innodb_redo/-- 2. 查看 InnoDB 恢复相关的指标SELECTNAME,COUNT,MAX_COUNTFROMinformation_schema.INNODB_METRICSWHERENAMEIN(os_log_pending_writes,-- 待写 redo 数量os_log_pending_fsyncs,-- 待 fsync 数量log_lsn_checkpoint_age,-- Checkpoint Agelog_max_modified_age_async,-- 异步刷脏阈值log_max_modified_age_sync-- 同步刷脏阈值到达时必须暂停写入等刷完)ORDERBYNAME;-- 3. 查看 Doublewrite 统计SHOWSTATUSLIKEinnodb_dblwr%;-- Innodb_dblwr_pages_written双写区写入的总页数-- Innodb_dblwr_writes双写操作的总次数-- 如果 pages_written / writes 远大于 1——说明合并写入效果好步骤四强制触发 Checkpoint 并观察效果-- 步骤目标通过调整参数观察 Checkpoint 推进对写道的影响-- 1. 记录当前状态SHOWENGINEINNODBSTATUS\G-- 记录 Last checkpoint at 和 Log sequence number-- 2. 执行大量写入DELIMITER//CREATEPROCEDUREstress_write_for_checkpoint()BEGINDECLAREiINTDEFAULT0;WHILEi50000DOUPDATEorders_largeSETamountamount0.01WHEREidi1;SETii1;IFi%50000THENCOMMIT;ENDIF;ENDWHILE;COMMIT;END//DELIMITER;CALLstress_write_for_checkpoint();-- 3. 手动触发 Checkpoint 推进通过 SET 调整低水位触发即时刷新SETGLOBALinnodb_max_dirty_pages_pct_lwm0;-- 低水位设为 0 → 立即开始刷新DOSLEEP(5);SETGLOBALinnodb_max_dirty_pages_pct_lwm10;-- 恢复默认-- 4. 再次查看 Checkpoint 是否已推进SHOWENGINEINNODBSTATUS\G-- Last checkpoint at 应该向前推进了步骤五读取崩溃恢复的源码级日志// 在编译时开启崩溃恢复的详细日志// cmake -DWITH_DEBUG1 ...// 在 recv_recovery_from_checkpoint_start() 中插入/* static int recovery_step 0; ib::info() [CRASH-RECOVERY] Step recovery_step : phase (recovery_in_progress ? REDO : ANALYSIS) , pages_processed n_pages_done , lsn current_lsn; // 编译后——在错误日志中可以看到 // [CRASH-RECOVERY] Step 1: phaseANALYSIS, pages_processed0 // [CRASH-RECOVERY] Step 2: phaseANALYSIS, pages_processed1523 // ... // [CRASH-RECOVERY] Step 57: phaseREDO, pages_processed12000 // ... // [CRASH-RECOVERY] Step 120: phaseUNDO, transactions_rolled_back3 */3.3 测试验证# 1. 查看 redo 写入速率每秒产生多少 MB redomysql-uroot-pRoot123-eSHOW ENGINE INNODB STATUS\G2/dev/null|grepLog sequencesleep10mysql-uroot-pRoot123-eSHOW ENGINE INNODB STATUS\G2/dev/null|grepLog sequence# 两次的差值 / 10 / 1024 / 1024 MB/s# 2. 查看 Checkpoint Age 是否健康mysql-uroot-pRoot123-eSHOW ENGINE INNODB STATUS\G2/dev/null|grep-A1Max checkpoint age# 3. 验证双写缓冲正常工作mysql-uroot-pRoot123-eSHOW STATUS LIKE innodb_dblwr%;# Innodb_dblwr_pages_written 0 说明正在使用# 4. 手动模拟崩溃恢复日志grep-icrash.recovery\|InnoDB.*recovery\|InnoDB.*redo\|InnoDB.*undo/var/log/mysql/error.log4. 项目总结优点 缺点维度优点缺点/局限WAL redo log顺序写 redo 远快于随机写数据页——写入吞吐提升 5-100 倍需要两倍写入量redo 数据页——SSD 寿命消耗翻倍Checkpoint 机制自适应脏页比例控制——防止 redo 循环覆盖激进刷新会导致 IO 毛刺保守刷新会导致 redo 容量紧张Doublewrite Buffer防止 torn page——崩溃恢复中最后的防线在 SSD 上写入放大 2 倍已写 redo dblwr data page原子写 SSD 无需双写崩溃恢复自动无需人工介入——全自动恢复时间依赖 Checkpoint Age——最坏情况数小时适用场景金融 / 支付必须双 1 配置 双写缓冲——数据安全性最高。高写入吞吐 OLTP增大 redo log 文件4GB减少 Checkpoint 频率——提高写入稳定性。SSD 存储考虑关闭双写缓冲如果 SSD 支持原子页写入innodb_doublewriteOFF——减少写入放大。源码级排障崩溃恢复失败时——通过插桩日志定位具体失败在哪个阶段哪个页。不适用场景纯内存数据库不需要 redo数据不安全但极快。批量导入临时关闭双写缓冲和 redo 刷盘——导入完再开启——可提升导入速度 2 倍。注意事项innodb_doublewriteOFF在非原子写 SSD 上会导致 torn page 无法恢复。Checkpoint 不能手动推进通过刷脏页间接控制——innodb_max_dirty_pages_pct_lwm是主要杠杆。修改 redo log 大小需要重启并删除旧文件操作前全量备份。常见踩坑经验故障案例一关闭双写缓冲后——一次掉电导致数十个数据页损坏。根因使用的 SSD 不支持原子页写入——4KB 写入是原子的——但 InnoDB 页是 16KB——可能被撕裂。修复重新开启双写缓冲——或使用支持 16KB 原子写的企业级 SSD。故障案例二Checkpoint Age 接近上限——所有写入暂停 3 分钟。根因innodb_io_capacity设置太低——刷脏速度跟不上写入速度。修复调大innodb_io_capacity到磁盘实际 IOPS 的 10-20%。故障案例三崩溃恢复进入死循环——Consume CPU 100% 但不前进。根因redo 文件中某条 redo 记录损坏——恢复时重复尝试应用——每次都失败但不退出。修复innodb_force_recovery 4跳过损坏页——启动后立即导出数据并重建。思考题如果 redo log 文件被手动删除——但数据文件还在——InnoDB 能启动吗数据能恢复吗双写缓冲在innodb_flush_methodO_DIRECT和O_DIRECT_NO_FSYNC下的行为有什么不同哪种更安全答案提示第 1 题——无法启动InnoDB 检测 redo 文件缺失直接 abort需要 innodb_force_recovery6 强制启动并导出数据重建实例第 2 题——O_DIRECT 在每次 fsync 时同时保证双写区和数据文件的刷盘O_DIRECT_NO_FSYNC 跳过部分 fsync——性能更高但对 OS crash 的防护更弱。延伸阅读与资源10倍开发者的 Dify 魔法书从零构建全栈 AI 应用后端工程师转型AI第一课-Ollama 与私有化大模型实战大型语言模型(LLM) vLLM 高性能推理落地实战Agent开发之LlamaIndex 实战修炼与源码进阶大语言模型Transformers 实战修炼与源码剖析