主机异常重启后MySQL启动崩溃，寻求InnoDB恢复正确方案

从你提供的mysqld.log来看，核心问题是断电导致InnoDB的purge线程校验失败（purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no断言错误），这是典型的InnoDB表空间或事务日志损坏场景。下面是经过验证的安全恢复步骤，每一步都要严格执行，避免数据丢失：

第一步：先做完整的数据备份！ #

这是所有恢复操作的前提，绝对不能跳过。先停止崩溃循环的mysqld服务，然后把整个MySQL数据目录备份到安全位置：

# 停止mysqld服务（根据系统不同也可使用service mysqld stop）
systemctl stop mysqld
# 创建带时间戳的备份目录，避免覆盖原有备份
cp -r /var/lib/mysql /var/lib/mysql_backup_$(date +%Y%m%d_%H%M%S)

备份完成后再进行后续操作，哪怕恢复失败，你还有原始数据可以重试。

第二步：逐步启用InnoDB强制恢复 #

InnoDB提供了innodb_force_recovery参数来跳过损坏的校验逻辑，我们从最低风险的级别开始尝试：

1. 编辑你的my.cnf文件，在[mysqld]段添加以下配置：

   [mysqld]
   # 保留所有原有配置，新增这一行
   innodb_force_recovery = 1
   

2. 尝试启动mysqld：

   systemctl start mysqld
   

3. 如果启动仍然崩溃，逐步提高级别到2、3、4、5、6（级别越高，跳过的校验越多，数据丢失风险越大）。注意：级别4及以上会让数据库处于只读模式，级别6是最后手段，会忽略所有损坏的页面。

第三步：成功启动后立刻导出所有数据 #

一旦MySQL成功启动，不要做任何写入操作，立刻用mysqldump导出所有数据库：

# 导出所有数据库，--single-transaction保证InnoDB数据一致性
mysqldump -u root -p --all-databases --single-transaction > all_databases_full_backup.sql

导出完成后，可以通过查看文件大小、用head/tail命令检查内容的方式，验证SQL文件的完整性。

第四步：重建InnoDB实例（彻底解决问题） #

强制恢复只是临时救急手段，必须重建实例才能彻底解决损坏问题：

1. 停止mysqld服务：

   systemctl stop mysqld
   

2. 清空原数据目录（确认备份存在再执行！）：

   rm -rf /var/lib/mysql/*
   

3. 初始化新的MySQL实例（MySQL 5.5版本使用mysql_install_db）：

   mysql_install_db --user=mysql --datadir=/var/lib/mysql
   

4. 编辑my.cnf，移除之前添加的innodb_force_recovery参数，保存后重启mysqld：

   systemctl start mysqld
   

5. 导入之前导出的全量数据：

   mysql -u root -p < all_databases_full_backup.sql
   

关键注意事项 #

• 不要在生产环境长时间运行在innodb_force_recovery模式下，这个模式仅用于数据导出，不能作为正常运行模式。
• 如果级别6都无法启动，说明InnoDB损坏非常严重，可能需要借助专业的数据恢复工具，或者从更早的物理备份恢复。
• 这次断电可能暴露了硬件问题，建议检查VM的存储磁盘、内存是否有故障，避免后续再次出现类似问题。

内容的提问来源于stack exchange，提问作者BTR Naidu