当遇到MySQL InnoDB表损坏导致服务器重启的问题，本文通过分析错误日志，揭示了由于数据页损坏引发的崩溃。解决方案包括使用`undrop-for-innodb`工具恢复以及通过SELECT语句备份损坏前的数据。尝试`check table`和`optimize table`命令以及设置`innodb_force_recovery`参数无效，因为它们无法修复损坏的数据页。
1. 版本
1)操作系统版本
cat /proc/version
Linux version 3.10.0-1062.9.1.el7.x86_64 (mockbuild@kbuilder.bsys.centos.org) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-39) (GCC) ) #1 SMP Fri Dec 6 15:49:49 UTC 2019
2)数据库版本
mysql> select version();
+-----------+
| version() |
+-----------+
| 8.0.17 |
+-----------+
1 row in set (0.00 sec)
2.问题描述
研发兄弟反馈说，他们的压测数据库中有一些表不能正常查询。我试了一下查询会报如下错误：
mysql> select * from test_part;
ERROR 2013 (HY000): Lost connection to MySQL server during query
日志中报错如下：
2020-07-06T17:42:52.413990+08:00 64 [ERROR] [MY-013183] [InnoDB] Assertion failure: btr0pcur.cc:318:page_is_comp(next_page) == page_is_comp(page) thread 140622855923456
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.
09:42:52 UTC - mysqld got signal 6 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
Thread pointer: 0x7fe0d80102c0
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 = 7fe54f5fdc30 thread_stack 0x46000
/usr/sbin/mysqld(my_print_stacktrace(unsigned char*, unsigned long)+0x3d) [0x1e435bd]
/usr/sbin/mysqld(handle_fatal_signal+0x333) [0xf25e83]
/lib64/libpthread.so.0(+0xf5f0) [0x7fe5cf88a5f0]
/lib64/libc.so.6(gsignal+0x37) [0x7fe5cdb9f337]<
最低0.47元/天 解锁文章
扫一扫
1895
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
