利用 Forcing InnoDB Recovery 特性解决 MySQL 重启失败的问题-CSDN博客

问题

由于异常断电或者系统异常重启时 MySQL 没有正常退出导致 MySQL 无法启动启动时报错如下

[System] [Server] /usr/sbin/mysqld (mysqld 8.0.30) starting as process 2665
[System] [InnoDB] InnoDB initialization has started.
[System] [InnoDB] InnoDB initialization has ended.
[ERROR] [InnoDB] Assertion failure: fut0lst.ic:81:addr.page == FIL_NULL || addr.boffset >= FIL_PAGE_DATA thread 140254438749952
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
08:02:18 UTC - mysqld got signal 6 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
Thread pointer: 0x7f8f800029d0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...

分析

从日志内容来看MySQL 在机器关机的时候有数据没有落地表空间损坏导致重启之后无法正常恢复线程在数据页中读取不到需要的 page 和数据。

需要做特殊操作让 MySQL 跳过恢复启动 MySQL然后把数据导出来再重建数据库导入。

MySQL 有个一个特性Forcing InnoDB Recovery启用这个特性需要设置 innodb_force_recovery 大于 0。

innodb_force_recovery 可以设置为 1-6大的值包含前面所有小于它的值的影响。

1 (SRV_FORCE_IGNORE_CORRUPT): 忽略检查到的 corrupt 页。尽管检测到了损坏的 page 仍强制服务运行。一般设置为该值即可然后 dump 出库表进行重建。

2 (SRV_FORCE_NO_BACKGROUND): 阻止主线程的运行如主线程需要执行 full purge 操作会导致 crash。 阻止 master thread 和任何 purge thread 运行。若 crash 发生在 purge 环节则使用该值。

3 (SRV_FORCE_NO_TRX_UNDO): 不执行事务回滚操作。

4 (SRV_FORCE_NO_IBUF_MERGE): 不执行插入缓冲的合并操作。如果可能导致崩溃则不要做这些操作。不要进行统计操作。该值可能永久损坏数据文件。若使用了该值则将来要删除和重建辅助索引。

5 (SRV_FORCE_NO_UNDO_LOG_SCAN): 不查看重做日志InnoDB 存储引擎会将未提交的事务视为已提交。此时 InnoDB 甚至把未完成的事务按照提交处理。该值可能永久性的损坏数据文件。

6 (SRV_FORCE_NO_LOG_REDO): 不执行前滚的操作。恢复时不做 redo log roll-forward。使数据库页处于废止状态继而可能引起 B 树或者其他数据库结构更多的损坏。

注意

为了安全当设置参数值大于 0 后可以对表进行 select, create, drop 操作,但 insert, update 或者 delete 这类操作是不允许的。MySQL 5.6.15 以后当 innodb_force_recovery 的值大于等于 4 的时候InnoDB 表处于只读模式。

在值小于等于 3 时可以通过 select 来 dump 表可以 drop 或者 create 表。MySQL 5.6.27 后大于 3 的值也支持 DROP TABLE

如果事先知道哪个表导致了崩溃则可 drop 掉这个表。如果碰到了由失败的大规模导入或大量 ALTER TABLE 操作引起的 runaway rollback则可 kill 掉 mysqld 线程然后设置 innodb_force_recovery = 3 使数据库重启后不进行 rollback。然后删除导致 runaway rollback 的表

如果表内的数据损坏导致不能 dump 整个表内容。那么附带 order by primary_key desc 从句的查询或许能够 dump 出损坏部分之后的部分数据

若使用更高的 innodb_force_recovery 值那么一些损坏的数据结构可能引起复杂的查询无法运行。此时可能只能运行最基本的 select * from table 语句。

解决方法

设置恢复模式启动 MySQL使 MySQL 跳过恢复步骤启动 MySQL将数据导出然后重建数据库在把数据重新导入。

vim /etc/my.cnf

添加配置项

innodb_force_recovery = 1

其中后面的值设置为1如果1不能启动再逐步增加为2/3/4/5/6等直到能启动 MySQL 为止。若不想尝试直接写6即可。

若启动时一直打印

 InnoDB: Waiting for the background threads to start

在 my.cnf 中的中增加innodb_purge_thread = 0 再尝试重启。

备份全部数据库表

mysqldump -uroot -p123456 --all-databases > all_mysql_backup.sql

删除 MySQL 数据清除之前务必先stop mysql服务

systemctl stop mysqld
cp -r /var/lib/mysql/ /var/lib/mysql.bak
rm -rf /var/lib/mysql/*

重启mysql服务

正常模式在启动 mysql

# innodb_force_recovery = 1
# innodb_purge_thread = 0

systemctl restart mysqld

使用之间备份的sql文件恢复数据

mysql -uroot -p123456 -e source /root/all_mysql_backup.sql

最后

这个方法仅仅是紧急情况下的一种补救不能依赖于这个办法最好是做好数据备份工作包括全备份和日志备份。确定要使用该方案是要确保有原始损坏数据的副本。4 以上的值可能永久导致数据文件损坏。务必在测试环境测试通过后再在生产环境使用。