mysql8错误InnoDB损坏！

mysql8错误InnoDB损坏！

早上发现公司的测试环境的mysql又又又挂了，上面一百多个库，测试同事要炸锅了。之前都是备份一下，然后恢复临时解决问题，今天打算换个思路来处理这个问题，先检查一下进程是否存在

ps -ef |grep mysqld


发现进程已经不存在了。

先打开配置中的innodb_force_recovery，这个配置

innodb_force_recovery = 1


这个配置的说明是这样的

innodb_force_recovery 是一个MySQL InnoDB存储引擎的参数，用于在数据库损坏时尝试恢复数据。当InnoDB存储引擎遇到不可恢复的错误时，该参数允许你通过强制InnoDB存储引擎启动并跳过某些检查来尝试恢复数据。
 
在默认情况下，innodb_force_recovery 参数的值为0，表示不启用强制恢复模式。如果需要启用强制恢复模式，则可以将该参数的值设置为1到6之间的整数，表示不同的恢复级别。每个级别都会执行一组特定的恢复操作。级别越高，执行的恢复操作越多，但也可能导致数据丢失或其他问题。
0：禁用强制恢复模式。
1：跳过事务ID的检查，并尝试恢复只有部分完成的事务。此级别通常不会导致数据丢失，但可能会导致一些数据不可用或无法更新。
2：跳过事务ID的检查，并尝试恢复已经提交的事务。此级别可能会导致一些数据丢失或重复，因此应该在备份数据之前使用该级别进行恢复。
3：跳过事务ID、页校验和和日志记录的检查，并尝试恢复已经提交的事务。此级别可能会导致数据丢失或重复，并且可能需要手动删除一些文件才能使数据库重新启动。
4：跳过事务ID、页校验和和日志记录的检查，并尝试恢复已经提交的事务。此级别与级别3相似，但还会尝试恢复数据字典中的表结构信息。
5：跳过事务ID、页校验和和日志记录的检查，并尝试恢复已经提交的事务。此级别与级别4相似，但还会尝试恢复所有的二进制日志文件。
6：类似于级别5，但还会尝试在恢复期间忽略错误的“undo”日志记录。
请注意，在使用 innodb_force_recovery 参数进行恢复之前，应该备份所有的数据，并在必要时咨询数据库管理员或专业人士的意见，以确保正确处理数据损坏问题。同时，应该避免在生产环境中使用强制恢复模式，因为它可能会导致数据丢失或其他问题。


先尝试配置1，然后启动mysql，启动这个后，数据库会锁定插入和修改等操作，只能读。

然后进行了一次数据库全表扫描，脚本如下：

[root@mysql105 ~]# cat mysqlcheck.sh 
#!/bin/bash
 
# MySQL用户名和密码
username="root"
password="你的密码"
 
# 获取数据库列表
databases=$(mysql -u $username -p$password -e "SHOW DATABASES" | grep -Ev "(Database|information_schema|performance_schema|mysql)")
 
# 输出文件名
output_file="./mysqlcheck_results.txt"
 
# 遍历数据库列表并执行 mysqlcheck，并将结果追加到输出文件
for db in $databases
do
  echo "Checking $db..."
  mysqlcheck -c -u $username -p$password $db >> $output_file
done
 
echo "Results have been saved to $output_file"


扫描过后，通过检查输出记录，发现好几张表的索引文件损坏了，关闭innodb_force_recovery参数，重启mysql，发现服务可以正常启动了。遍历的部分结果如下

xxxxount_service.xxxsic_info
Warning  : InnoDB: The B-tree of index PRIMARY is corrupted.
Warning  : InnoDB: Index 'id_card_number' contains 1253338 entries, should be 18446744073709551615.
error    : Corrupt
 
xxxxount_service.xxxsic_info
Warning  : InnoDB: The B-tree of index ix_project_id is corrupted.
error    : Corrupt


尝试重建表索引：

##重建表索引，这将强制MySQL删除并重新构建表和索引。注意，这可能会导致数据丢失，因此请务必在执行此操作之前进行备份。
ALTER TABLE databases_name.table_name ENGINE=InnoDB;


执行后，倒是没影响程序。目前mysql是正常了，后续在观察吧。。