mysql8.0异常宕机报错[MY-012095] [InnoDB] [FATAL] Tablespace id is 305

mysql8.0异常关闭导致问题

1.修改my.cnf参数innodb_force_recovery = 6然后在重启mysqld服务；

2.再次修改配置文件my.cnf注释掉该上，然后在重启mysqld服务

3.删除出现问题的表结构，然后在新建表结构

经查看日志发现ibd文件损坏

这个库的这个表的`new-taxes-xxl-job`.`xxl_job_log的ibd文件损坏，其中存放的是没有用的log日志记录，大概有几百万条数据

后台的idb文件是9个G

报错信息

17174 2022-06-13T09:01:53.599258Z 11 [ERROR] [MY-012095] [InnoDB] [FATAL] Tablespace id is 305 in the data dictionary but in file ./new@002dtaxes@002dxxl@002djob/xxl_job_log.ibd it is 104!

17175 2022-06-13T09:01:53.599298Z 11 [ERROR] [MY-013183] [InnoDB] Assertion failure: fil0fil.cc:2582:ib::fatal triggered thread 139924019848960

存储引擎是InnoDB, 在data目录下会看到2类文件：.frm、.ibd

（1）*.frm–表结构的文件。

（2）*.ibd–表数据和索引的文件。该表的索引(B+树)的每个非叶子节点存储索引，叶子节点存储索引和索引对应的数据。

解决方法：

修改mysql的配置文件/etc/my.cnf

新增

innodb_force_recovery = 6

然后重新启动

systemctl restart mysqld

并查看日志

tail -f /var/log/mysqld.log

出现故障前的事务不进行回滚操作

数据扫描到这里出现了错误，证明这个表的ibd文件损坏，将该表重建同步或者将备份的数据同步到表中；

由于mysql宕机了，导致业务都程序启动报错，正好是log日志表，就直接删除了这个表，然后进行新建的

 Trying to get some variables.

 Some pointers may be invalid and cause the dump to abort.

 Query (7f00980b2cb0): SELECT id FROM `xxl_job_log`   WHERE !(    (trigger_code in (0, 200) and handle_code = 0)    OR    (handle_code = 200)   )   AND `alarm_status` = 0   ORDER BY id ASC   LIMIT 1000

21945 Connection ID (thread ID): 11

21946 Status: NOT_KILLED

定位之后修改mysql的配置文件/etc/my.cnf

更改注释这项

#innodb_force_recovery = 6

然后重新启动

systemctl restart mysqld

并查看日志

tail -f /var/log/mysqld.log

这是由于这个表的ibd是错误的后台一直在刷这个错误

直接连接上Navicat或者mysql编辑框删除这个表，然后在新建这个表就完整了

只同步表结构即可

如果不放心可以删除重建表，并同步表结构完成后，再次重启一下查看一下日志

2022-06-13T09:07:37.001658Z 12 [Warning] [MY-012049] [InnoDB] Cannot calculate statistics for table `new-taxes-xxl-job`.`xxl_job_log` because the .ibd file is missing. Please refer to http://dev.mysql.com/doc/refman/8.0/en/innodb-      troubleshooting.html for how to resolve the issue.

如果是业务表的ibd文件损坏，还是要进行binglog二进制文件恢复数据操作，也有业务数据的表直接删除影响很大

mysql binlog

查看binglog日志设置的过期时间

​

show variables like 'expire_logs_days';
show variables like '%binlog_expire_logs_seconds%';
show binary logs;

​将binlog.000060之前的binglog日志都清除掉

purge master logs to 'binlog.000060';

清理超过30天的binlog日志

flush logs

使用binlog二进制文件进行恢复数据中的一部分，找开始点和结束点

157和2973就是一个commit的开始点和结束点

依次执行

即可导入这两个节点之间的数据

mysqlbinlog --start-position=157 --stop-position=2973 --database=new-taxes -v /var/lib/mysql/binlog.000002 > binlog_rec.txt
mysql -uroot -p123456  < binlog_rec.txt

通过后台grep找

找开始点

mysqlbinlog --base64-output='DECODE-ROWS' /var/lib/mysql/binlog.000002 | grep -C20 -i 'zabbix'|more

找结束点

mysqlbinlog --base64-output='DECODE-ROWS' /var/lib/mysql/binlog.000002 | tail -100

找COMMIT/*!*/;

# at 95014616

代表的结束点

恢复整个binglog二进制文件

通过时间进行查找

mysqlbinlog --base64-output=decode-rows -v --start-datetime='2021-01-01 00:00:00' --stop-datetime='2021-11-30 00:00:00' -d 库名 二进制文件 --result-file 输出文件名