mysql InnoDB的崩溃恢复过程是什么
2024-03-13 20:26:22
MySQL InnoDB的崩溃恢复过程主要分为以下几个关键步骤：
检查点（Checkpoint）验证
扫描redo log，定位最近的MLOG_CHECKPOINT记录，确认检查点LSN（Log Sequence Number）。
若检查点LSN为0，需验证redo log的完整性；若存在损坏且未启用强制恢复（srv_force_recovery），则报错退出。
目的：确保从正确的位置开始恢复，避免数据不一致。
日志与数据文件一致性校验
比较检查点LSN与数据文件头记录的flush LSN。若不一致，可能提示使用了错误的日志文件或数据文件损坏。
在只读模式下禁止恢复；否则初始化崩溃恢复流程（recv_init_crash_recovery）。
目的：检测是否需要恢复，避免重复操作或错误覆盖。
Redo Log重放（Redo Phase）
从检查点LSN开始重放redo log，将已提交事务的修改应用到数据页，确保持久性。
若启用强制恢复（如SRV_FORCE_NO_LOG_REDO），可能跳过此步骤。
核心操作：通掘肢过recv_group_scan_log_recs扫描并应用日志记录，更新LSN。
Undo Log回滚（Undo Phase）
回滚未提交事务的修改，通过undo log将数据链散并页恢复到事务前的状态。
目的：保证原子性，避免脏写。
写缓冲（Change Buffer）合并
将写缓冲中的二级索引修改合并到实际数据页，确保索引一致性。
触发条件：仅在恢复过程中处理未合并的写缓冲记录。
Purge操作
后台线程清理标记为删除的旧数据版本，释放空间。
特点：与崩溃恢复解耦，属常规维护机制。
恢复完成与LSN更新
设置系统LSN为恢复后的值（recv_sys->recovered_lsn）。
若棚迹需重新扫描日志（如初始扫描不完整），再次执行recv_group_scan_log_recs。
异常处理
- 若发现日志损坏（found_corrupt_log）或文件系统错误（found_corrupt_fs），且未启用强制恢复，立即终止恢复并报错。
- 通过srv_force_recovery参数可跳过部分检查，但可能导致数据不一致。
总结
InnoDB崩溃恢复通过redo重放确保已提交数据的持久性，undo回滚维护未提交事务的原子性，并结合写缓冲合并与purge操作，最终将数据库恢复到一致状态。整个过程高度依赖日志系统的完整性和检查点机制。
热门标签
