mysql报错 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace -MySQL-运维笔记-技术文档

因为我之前是删除ib_logfile0文件恢复的，所以才报的这个错

还有这个错

日志上已经提示了，去官网就可以找到答案

先贴答案

sudo vim /etc/mysql/mariadb.conf.d/50-server.cnf

添加innodb_force_recovery = 1就可以解决

以下摘抄自官网

模式	说明
0	InnoDB正常运行时的默认模式。允许写事务的innodb_force_recovery<=4。
1	(SRV_FORCE_IGNORE_CORRUPT）允许服务器保持运行，即使检测到损坏的页面。它通过使基于重做日志的恢复忽略某些错误来做到这一点，例如丢失的数据文件或损坏的数据页。将跳过受影响文件或页的任何重做日志。通过使SELECT * FROM table_name语句跳过损坏的索引和页，可以简化转储表。
2	(SRV_FORCE_NO_BACKGROUND）停止主线程运行，防止在清除期间发生崩溃。将不执行清除，因此撤消日志将继续增长。
3	(SRV_FORCE_NO_TRX_UNDO）在崩溃恢复后不回滚事务。不影响当前活动事务的回滚。还将阻止一些撤消生成的后台任务运行。由于已恢复的未完成事务的回滚被阻止，这些任务可能会遇到锁等待。
4	(SRV_FORCE_NO_IBUF_MERGE）与3相同。
5	(SRV_FORCE_NO_UNDO_LOG_SCAN）将未完成的事务视为已提交，并且在启动时不查看撤消日志。
6	(SRV_FORCE_NO_LOG_REDO）不执行重做日志前滚作为恢复的一部分。在此模式处于活动状态时，运行需要索引的查询可能会失败。但是，如果表转储仍然导致崩溃，您可以尝试使用`SELECT * FROM tab ORDER BY primary_key DESC`转储损坏部分之后的所有数据部分。

来自 MariaDB 10.6.5

模式	说明
0	InnoDB正常运行时的默认模式。允许写事务的innodb_force_recovery<=4。
1	(SRV_FORCE_IGNORE_CORRUPT）允许服务器保持运行，即使检测到损坏的页面。它通过使基于重做日志的恢复忽略某些错误来做到这一点，例如丢失的数据文件或损坏的数据页。将跳过受影响文件或页的任何重做日志。通过使SELECT * FROM table_name语句跳过损坏的索引和页，可以简化转储表。
2	(SRV_FORCE_NO_BACKGROUND）停止主线程运行，防止在清除期间发生崩溃。将不执行清除，因此撤消日志将继续增长。
3	(SRV_FORCE_NO_TRX_UNDO）在崩溃恢复后不回滚DML事务。不影响回滚当前活动的DML事务。还将阻止一些撤消生成的后台任务运行。由于已恢复的未完成事务的回滚被阻止，这些任务可能会遇到锁等待。
4	(SRV_FORCE_NO_DDL_UNDO）在崩溃恢复后不回滚事务。不影响当前活动事务的回滚。还将阻止一些撤消生成的后台任务运行。由于已恢复的未完成事务的回滚被阻止，这些任务可能会遇到锁等待。
5	(SRV_FORCE_NO_UNDO_LOG_SCAN）将未完成的事务视为已提交，并且在启动时不查看撤消日志。InnoDB将基本上忽略InnoDB表的任何DDL日志，但服务器将启动
6	(SRV_FORCE_NO_LOG_REDO）不执行重做日志前滚作为恢复的一部分。在此模式处于活动状态时，运行需要索引的查询可能会失败。但是，如果表转储仍然导致崩溃，您可以尝试使用`SELECT * FROM tab ORDER BY primary_key DESC`转储损坏部分之后的所有数据部分。

还请注意，XtraDB（<=MariaDB 10.2.6）默认情况下，当它在单表表空间中检测到损坏的数据时，会使服务器崩溃。可以更改此行为-请参阅innodb_corrupt_table_action系统变量。

修理东西

尝试将innodb_force_recovery设置为1并启动mariadb。如果失败，请尝试值“2”。如果值为2，那么您遇到的唯一损坏可能是在innodb“undo logs”中。如果mariadb启动了，你应该可以用mysqldump转储你的数据库。您可以通过运行“mysqlcheck --all-databases”来验证任何表的任何其他问题。

如果您能够成功转储数据库，或者之前已知的备份良好，请从mariadb命令行删除数据库，如“DROP DATABASEyourdatabase”。停止mariadb。转到/var/lib/mysql（或者你的mysql数据目录所在的任何地方）和“rm -i ib*"。启动mariadb，创建您删除的数据库（“CREATE DATABASE ASYourdatabase”），然后导入您最近的转储：“mysql<mydatabasedump.sql”

模式	说明
0	InnoDB正常运行时的默认模式。在 MariaDB 10.2.7之前，它是唯一允许更改数据的模式。从 MariaDB 10.2.7开始，允许innodb_force_recovery =3的写事务<。
1	(SRV_FORCE_IGNORE_CORRUPT）允许服务器保持运行，即使检测到损坏的页面。它通过使基于重做日志的恢复忽略某些错误来做到这一点，例如丢失的数据文件或损坏的数据页。将跳过受影响文件或页的任何重做日志。通过使SELECT * FROM table_name语句跳过损坏的索引和页，可以简化转储表。
2	(SRV_FORCE_NO_BACKGROUND）停止主线程运行，防止在清除期间发生崩溃。将不执行清除，因此撤消日志将继续增长。
3	(SRV_FORCE_NO_TRX_UNDO）在崩溃恢复后不回滚事务。不影响当前活动事务的回滚。从 MariaDB 10.2.7开始，还将阻止一些undo生成的后台任务运行。由于已恢复的未完成事务的回滚被阻止，这些任务可能会遇到锁等待。
4	(SRV_FORCE_NO_IBUF_MERGE）不计算表统计信息并阻止插入缓冲区合并。
5	(SRV_FORCE_NO_UNDO_LOG_SCAN）将未完成的事务视为已提交，并且在启动时不查看撤消日志。
6	(SRV_FORCE_NO_LOG_REDO）不执行重做日志前滚作为恢复的一部分。在此模式处于活动状态时，运行需要索引的查询可能会失败。但是，如果表转储仍然导致崩溃，您可以尝试使用`SELECT * FROM tab ORDER BY primary_key DESC`转储损坏部分之后的所有数据部分。