MySQL引擎无法启动、重启陷入循环且innodb_force_recovery=4备份失败求助

看起来你碰到了InnoDB的棘手损坏问题——这种fut0lst.ic:82处的断言失败，意味着InnoDB的核心空闲页管理链表已经出现底层损坏，连innodb_force_recovery=4都搞不定的话，得试试更激进的方案，或者从备份入手。先一步步来：

首先明确你的错误日志关键信息（方便定位问题）：

2024-09-21T11:41:21.146039Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.39-0ubuntu0.20.04.1) starting as process 287290
2024-09-21T11:41:21.155269Z 0 [Warning] [MY-013907] [InnoDB] Deprecated configuration parameters innodb_log_file_size and/or innodb_log_files_in_group have been used to compute innodb_redo_log_capacity=1073741824. Please use innodb_redo_log_capacity instead.
2024-09-21T11:41:21.156630Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2024-09-21T11:41:23.407433Z 0 [ERROR] [MY-013183] [InnoDB] Assertion failure: fut0lst.ic:82:addr.page == FIL_NULL || addr.boffset >= FIL_PAGE_DATA thread 140535711876864
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug ...

方案一：尝试最高等级的强制恢复模式 #

这是能尝试导出数据的最后常规手段：

• 先彻底停掉所有MySQL相关进程：

  sudo systemctl stop mysql
  # 确认进程都已终止，没终止的话手动杀掉
  sudo kill -9 $(pgrep mysqld)
  

• 编辑MySQL配置文件（Ubuntu 20.04通常在/etc/mysql/mysql.conf.d/mysqld.cnf或者/etc/mysql/my.cnf），把innodb_force_recovery改成6（这是最高等级，会跳过所有损坏的索引、数据结构校验，只保证能启动MySQL以便导出数据）：

  [mysqld]
  innodb_force_recovery = 6
  

• 启动MySQL：

  sudo systemctl start mysql
  

• 如果成功启动，立刻导出所有数据库（哪怕有警告也要继续，能导多少是多少）：

  mysqldump -u root -p --all-databases > full_emergency_backup.sql
  

• 导出完成后立刻停掉MySQL，绝对不要在recovery=6模式下运行业务——这个模式是只读且跳过了大量校验，数据完整性无法保证。

方案二：清理Redo日志后再尝试恢复 #

如果recovery=6还是启动失败，可能是Redo日志损坏导致的连锁问题：

• 先停掉所有MySQL进程（同方案一第一步）
• 备份整个MySQL数据目录（做任何操作前必须备份，绝对不能动原数据！）：

  sudo cp -r /var/lib/mysql /var/lib/mysql_emergency_backup_$(date +%Y%m%d)
  

• 进入MySQL数据目录，删除Redo日志和临时表空间文件：

  cd /var/lib/mysql
  sudo rm ib_logfile* ibtmp1
  

• 把innodb_force_recovery改回4或者6，再次尝试启动MySQL，成功后立刻导出数据。

方案三：如果以上都不行，只能从备份恢复或尝试单表提取 #

• 如果你有之前的全量备份，直接恢复备份是最快最稳妥的办法——这也是为什么日常备份如此重要。
• 如果没有备份，只能尝试提取单个表的数据：在干净的MySQL实例中创建和损坏表完全相同结构的表，然后用ALTER TABLE ... DISCARD TABLESPACE，把损坏实例中对应表的.ibd文件拷贝过来，再执行ALTER TABLE ... IMPORT TABLESPACE。不过这个方法成功率极低，因为系统表空间（ibdata1）已经损坏的话，表结构元数据可能也出问题了。

后续注意事项 #

• 恢复完成后，立刻做一次全量备份，避免再次出事。
• 升级MySQL到对应系列的最新小版本（比如你的8.0.39可以更到Ubuntu仓库里的最新8.0.x版本），这类断言失败可能是已知bug，新版本可能已经修复。
• 检查磁盘健康：这种底层损坏很多时候是磁盘IO错误导致的，用smartctl -a /dev/sda（替换成你的磁盘设备）检查SMART信息，看有没有坏道或IO异常。

备注：内容来源于stack exchange，提问作者Enihr