NAS MySQL 崩溃与恢复记录（2026-09-27）

绿联 DXP4800 上的 Docker MySQL（8.0.34）自 9 月中旬起无法启动，连带 Gitea 约每 30 秒重启。2026-09-27 完成数据抢救与重建，记录如下备查。

现象

• MySQL 容器 Exited (128)，主机无 mysqld、3306 无人监听
• Gitea（依赖 mysql:3306）连环重启；WordPress / frpc 等仍在跑
• 磁盘充足，非 OOM（OOM=false）

根因

InnoDB redo 日志缺失。容器日志反复出现：

[ERROR] [MY-013882] Missing redo log file ./#innodb_redo/#ib_redo1388
(with start_lsn = 4545363968)
→ Plugin initialization aborted
→ Data Dictionary initialization failed
→ Aborting

数据目录 #innodb_redo/ 中仅有 #ib_redo1386/1387 与 #ib_redo1418…1422，中间缺 #ib_redo1388。检查点仍引用该文件，故无法启动。

时间线

• 2026-09-02 13:06–14:25：数据目录最后实质写入（ibdata1 / redo / binlog）
• 2026-09-02 15:42：绿联 Docker 引擎异常（docker.sock ping 超时）
• 2026-09-18：引擎恢复后 MySQL 反复 Abort（同一缺 redo 错误）；后因 cgroup/runc 停在 Exit 128
• 2026-09-27：force_recovery 导出 → 重建实例 → 导入 → 服务拉齐

恢复步骤

1. 停依赖容器，整目录备份到 /home/ray/data/mysql.corrupt.20260927_114702
2. 以 --innodb-force-recovery=1…6 尝试只读拉起；level=6 成功
3. mysqldump 导出：gitea.sql（约 3.0M）、wp.sql（约 1.3M）→ /home/ray/data/mysql_dump_20260927_114702/
4. 空数据目录重新初始化 MySQL 8.0.34，导入 dump
5. 切回 compose 自定义 entrypoint，拉起 gitea / wordpress / frpc
6. 清理旧容器名冲突后：mysql healthy，整栈恢复

脚本：/home/ray/scripts/service_deploy/container/recover_mysql_innodb.sh

经验与后续

• 缺 redo 时通常需要 innodb_force_recovery=6；能连上后立刻 dump，不要当正常库长期跑
• entrypoint 的 chmod -R a+rwX 会使 auto.cnf world-writable 被 mysqld 删除（次要问题）
• 定期逻辑备份（mysqldump）比只留数据目录更稳妥；旧镜像包救不了数据
• 损坏目录与 dump 仍在 /home/ray/data/，确认无误后再删

记录于恢复当日，便于以后同类故障对照。