mysql数据损坏修复(InnoDB: Error: page 5 log sequence number 836321191877)

相关报错：

2021-11-18 10:56:14 7fcd38b3b780 InnoDB: Error: page 5 log sequence number 836321191877
InnoDB: is in the future! Current system log sequence number 836321150789.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: for more information.
​
02:56:16 UTC - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
​
​

日志中判断是由于误操作导致innodb引擎出了问题

强制恢复数据相关文档： http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html

innodb_force_recovery影响整个InnoDB存储引擎的恢复状况。默认为0，表示当需要恢复时执行所有的恢复操作（即校验数据页/purge undo/insert buffer merge/rolling back&forward），当不能进行有效的恢复操作时，mysql有可能无法启动，并记录错误日志；（可以在/etc/my.cnf设置记录错误日志（便于排查））

恢复操作：
在/etc/my.cnf  添加配置
innodb_force_recovery = 6
innodb_purge_thread = 0
​
​
重启mysql
​
这时只可以执行select,create,drop操作，但不能执行insert,update,delete操作。
​
使用mysql工具查找数据库中哪些数据已损坏
  cd /home/data/app/mysql/mysql/bin
  ./mysqlcheck -uroot -p --socket=/tmp/mysql3306.sock  库名     -c   #检查库中有哪些表已损坏   
​
找到已经损坏的表:使用
mysqlcheck -uroot -ppasswd 库名  -r  # 修复整个数据库，innodb引擎不支持修复(我们的MySQL使用的是innodb引擎 不支持此操作 )
​
（1）如果数据有备份；
    【1】直接删除已经损坏的库或者表
      删除掉
      cd /home/data/app/mysql/databak_1109/data/shenqics_rel20180608
      rm -rf  LG_UserRewardReceive.*  
      rm /home/data/app/mysql/databak_1109/data/ibdata1 # ibdata1是存放mysql的数据和索引
      rm /home/data/app/mysql/databak_1109/data/ib_logfile* # ib_logfileN是redo   log事务日志文件
​
     【2】启动  重启操作
 
（2）如果数据无备份；
​
     【1】找到损坏的表使用mysqldump导出
       mysqldump -uroot -ppasswd database table1 table2 > database.table.sql  #导出数据
     【2】到数据目录下删除已经损毁的库或表
       /home/data/app/mysql/databak_1109/data/shenqics_rel20180608
       rm -rf  LG_UserRewardReceive.*
     【3】执行 重启操作  
        重启操作后导出之前已经损毁的数据的表或者库
        mysql -uroot -ppasswd database < database.table.sql
        
​
【重启操作】：
在/etc/my.cnf  删除掉配置
#innodb_force_recovery = 6
#innodb_purge_thread = 0
######测试环境没有配置软链接启动 
#启动和重启方式
cd /home/data/app/mysql/mysql
./bin/mysqld restar
​
 重启后新建删除掉的表即可  或者 重启后导入之前已经导出的损毁的数据的表或者库
#######相关参数解释###################################################
​
​
可以使用innodb_force_recovery参数，使mysqld跳过恢复步骤，启动mysqld，将数据导出然后重建数据库。
​
innodb_force_recovery 可以设置为1-6，大的数字包含前面所有数字的影响
​
1.(SRV_FORCE_IGNORE_CORRUPT):忽略检查到的corrupt页。
2.(SRV_FORCE_NO_BACKGROUND):阻止主线程的运行，如主线程需要执行full purge操作，会导致crash。
3.(SRV_FORCE_NO_TRX_UNDO):不执行事务回滚操作。
4.(SRV_FORCE_NO_IBUF_MERGE):不执行插入缓冲的合并操作。
5.(SRV_FORCE_NO_UNDO_LOG_SCAN):不查看重做日志，InnoDB存储引擎会将未提交的事务视为已提交。
6.(SRV_FORCE_NO_LOG_REDO):不执行前滚的操作。
​
#innodb_purge_thread   不启动协调线程
#一般来讲我们理解的purge线程可以做如下的工作：
#1.清理del flag标签的记录
#2清理undo的历史版本
#3如果需要进行undo tablespace截断。
#4其包含一个协调线程和多个工作线程
###########################################################################

参考文档：mysql innodb启动失败无法重启的处理方法_傲雪星枫-CSDN博客

参考文档：InnoDB存储引擎 - 常见问题修复_沈猪猪_51CTO博客