17370845950

MySQL崩溃后能否恢复取决于是否开启log_bin、InnoDB表空间是否物理损坏及最近备份是否有效；满足binlog开启且有可用全量备份时，95%场景可完整恢复。

MySQL 崩溃后能否恢复，取决于三件事：是否开启了 log_bin、InnoDB 表空间是否物理损坏、以及最近一次备份是否有效。只要 binlog 开启 + 有可用全量备份，95% 的崩溃场景（包括误删、断电、服务异常退出）都能完整恢复；若表空间已报 InnoDB: Database page corruption 或 Tablespace has been discarded，则必须走 innodb_force_recovery 分级抢救或从物理备份重建。

确认崩溃类型：看错误日志里有没有这三行关键提示

别急着重启，先查 /var/lib/mysql/hostname.err（或 mysqld.log）：

• InnoDB: Database was not shut down normally → 属于「软崩溃」，InnoDB 能自动重放 redo log，大概率启动即恢复
• InnoDB: Database page corruption on disk 或 page 5 类似报错 → 「硬损坏」，磁盘/文件系统出问题，需强制恢复或换备份
• Can't open shared memory segment 或 Address already in use → 非数据损坏，只是 mysqld 残留进程没清干净，killall mysqld 再试

如果日志里反复出现 srv_master_thread looped 或 cannot allocate memory，说明不是崩溃而是 OOM 导致假死，应优先调大 innodb_buffer_pool_size 并检查连接数。

能启动但数据不一致？立刻停写，用 innodb_force_recovery 分级导出

当 MySQL 能启动但查询报错（如 ERROR 2013 (HY000): Lost connection to MySQL server during query），说明部分页已损坏，但缓冲池还能加载部分数据 —— 这时不能直接 dump，得靠分级强制恢复抢出可用数据：

[mysqld]
innodb_force_recovery = 1
innodb_purge_threads = 0

从 1 开始试，每级只加 1，成功启动后立即执行：

• mysqldump --single-transaction --routines --triggers --all-databases > full_backup.sql
• 导出成功后，**立刻注释掉 innodb_force_recovery 并重启服务**（该参数开启时禁止写入，且跳过崩溃恢复逻辑）
• 若 =1 失败，再试 =3（跳过 undo 回滚）、=6（跳过 redo 重放）——但注意：=6 会丢失未刷盘的事务，仅作最后手段

切记：innodb_force_recovery 不是修复命令，它只是“绕过检查强行读”，导出的数据可能缺行或字段为空，务必在测试库验证后再上线。

binlog 恢复必须满足两个前提，缺一不可

想用 mysqlbinlog 做时间点恢复（PITR），光有 mysql-bin.0000xx 文件远远不够：

• 前提 1： 启动时必须带 --server-id=非0值（哪怕单机也要设），否则 binlog 事件不记录 XID，崩溃恢复时无法关联 redo log 和 binlog 事务
• 前提 2： 全量备份必须是 mysqldump --master-data=2 或 xtrabackup 生成的，否则你不知道备份对应哪个 binlog 文件和 position

典型恢复链路：

mysql < full_backup.sql
mysqlbinlog --start-position=12345 mysql-bin.000012 | mysql
mysqlbinlog --stop-datetime="2025-12-29 14:22:00" mysql-bin.000013 | mysql

如果执行时报 ERROR 1062 (23000) at line XXX: Duplicate entry，说明 binlog 里有重复 DDL（如两次 CREATE TABLE），需加 --skip-gtids 或手动过滤掉建表语句。

最常被忽略的致命细节：备份有效性验证必须离线做

很多团队备份脚本每天跑成功，但从未验证过备份文件能不能用。真实故障时才发现 backup.sql 最后 10MB 是空的，或 mysql-bin.000123 校验失败：

• 逻辑备份验证：head -n 50 backup.sql | grep "CREATE TABLE" 看建表语句是否存在；再用 mysql -e "CREATE DATABASE test_restore;" + mysql test_restore 测试导入是否中断
• binlog 完整性验证：mysqlbinlog --verify-binlog-checksum /var/lib/mysql/mysql-bin.000123 > /dev/null，返回 0 才算合格
• 物理备份验证：用 xbstream -x 解压后，检查 xtrabackup_checkpoints 中的 to_lsn 是否连续

所有验证操作必须在隔离环境（Docker 或临时 VM）中完成，绝不能在生产库上解压或导入 —— 曾有团队因在生产库执行 xbstream -x 占满磁盘导致二次宕机。