利用 Forcing InnoDB Recovery 特性解决 MySQL 重启失败的问题
问题
由于异常断电或者系统异常重启时 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 以上的值可能永久导致数据文件损坏。务必在测试环境测试通过后再在生产环境使用。