[InnoDB] #CORRUPT LOG RECORD FOUND#[MySQL InnoDB表空损坏，数据库无法启动]#

最新推荐文章于 2023-08-30 10:46:57 发布

KALI_LINUX_HACK

最新推荐文章于 2023-08-30 10:46:57 发布

阅读量1.7k

点赞数 3

CC 4.0 BY-SA版权

文章标签： mysql

本文链接：https://blog.youkuaiyun.com/KALI_LINUX_HACK/article/details/124356521

1.写在前面（具体报错）信息

# MySQL Version ：8.0.27 MySQL Community Server - GPL
#有很多类似这样的报错，我这里截取了完整的一段

[root@zbxserver1 ~]# tailf -100 /var/log/mysqld.log 
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
2022-04-22T14:22:22.913109Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.27) starting as process 111450
2022-04-22T14:22:22.922078Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2022-04-22T14:22:23.202346Z 1 [ERROR] [MY-012519] [InnoDB] ############### CORRUPT LOG RECORD FOUND ###############
 len 170; hex 085181f4003800001a9905265181f4000300038008800480062be2026f1f02fbee80cc00380501fbee80cc006a0104fbee80cc00840104fbee80cc00881804fbee80cc008c00880005002600001d300119fbef81b200001d300102fbef81b20028afd402fbef81b2002aafd402fbef81b22eebafd401fbef81b22eee011f94fbef81b2001b5c00001f0000001d0d01c1000001b2267408000000000000000300a9fbfe84b60009000180; asc  Q   8     &Q            +  o       8       j                             &   0         0       (        *       .        .          \              &t                    ;
2022-04-22T14:22:23.202885Z 1 [ERROR] [MY-013183] [InnoDB] Assertion failure: log0recv.cc:4008 thread 139666151679744
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.
14:22:23 UTC - mysqld got signal 6 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
Thread pointer: 0x6d1bae0
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...
stack_bottom = 7f068f5b9bf0 thread_stack 0x100000
/usr/sbin/mysqld(my_print_stacktrace(unsigned char const*, unsigned long)+0x3d) [0x1fc33ad]
/usr/sbin/mysqld(handle_fatal_signal+0x30b) [0xee902b]
/lib64/libpthread.so.0(+0xf630) [0x7f069e628630]
/lib64/libc.so.6(gsignal+0x37) [0x7f069cb72387]
/lib64/libc.so.6(abort+0x148) [0x7f069cb73a78]
/usr/sbin/mysqld() [0xc3378c]
/usr/sbin/mysqld(recv_recovery_from_checkpoint_start(log_t&, unsigned long)+0xe88) [0x215a838]
/usr/sbin/mysqld(srv_start(bool)+0x1bd6) [0x220e356]
/usr/sbin/mysqld() [0x20a45bd]
/usr/sbin/mysqld(dd::bootstrap::DDSE_dict_init(THD*, dict_init_mode_t, unsigned int)+0x8b) [0x1d87ddb]
/usr/sbin/mysqld(dd::upgrade_57::do_pre_checks_and_initialize_dd(THD*)+0x1a0) [0x1f969c0]
/usr/sbin/mysqld() [0xfab2d6]
/usr/sbin/mysqld() [0x248d620]
/lib64/libpthread.so.0(+0x7ea5) [0x7f069e620ea5]
/lib64/libc.so.6(clone+0x6d) [0x7f069cc3ab0d]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0): Connection ID (thread ID): 1
Status: NOT_KILLED

报错截图

mysql innodb报错截图

2.查找资料

直接搜索报错，找了老半天也没找到，心情相当烦躁，真是怕什么来什么。思索片刻后，打算换种思路来解决这个问题（后来也证明了我是对的）。于是，我把目光又移回到了报错信息上。发现了这么一条一段话。

InnoDB: about forcing recovery.
14:22:24 UTC - mysqld got signal 6 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.

大致意思就是说可以跳过错误，强势启动MySQL。
查阅各方资料找到这个参数

#忽略检查，有6个级别
innodb_force_recovery=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 树或者其他数据库结构更多的损坏。

3.修改配置文件

#建议是从1开始逐级往上加

[root@zbxserver1 ~]# vim /etc/my.cnf
[mysqld]
innodb_force_recovery=6

4.重启mysql

#然后数据库就起来了

[root@zbxserver1 ~]# systemctl restart mysqld

5.备份业务库

#数据库虽然起来了，但是现在是没办法用的，无法新增数据。
#不过数据库起来的就好办，需要准备一个新库，将重要的业务库全备出来，然后在恢复到新库。

mysql> create database test001;
ERROR 1836 (HY000): Running in read-only mode

备份业务库，我这上面跑zabbix server的数据库，所以只业务库就是zabbix这个库。

[root@zbxserver1 ~]# mysqldump -uroot -p -B zabbix -R --triggers --single-transaction --source-data=2 > /tmp/zabbix_data.sql
Enter password:  #输入密码

6.导入新库

#提前准备好新库，最好是同版本的mysql，再不济也要能支持Innodb存储引擎的（mysql5.6及以上）。

[root@zbxserver2 ~]# mysql -uroot -p < /tmp/zabbix_data.sql

7.把业务割接到新库

8.写在最后

作为一名数据库小白，总觉得有更好的解决办法，所有记录一下，记录一下
希望大佬指点