由于数据库损坏，MySQL 无法启动

Posted 2023-03-23

【中文标题】由于数据库损坏，MySQL 无法启动

【英文标题】：MySQL cannot start due to a database corruption

【发布时间】：2018-03-15 05:59:27

【问题描述】：

日志：

10 月 3 日 22:00:46 ip-172-31-3-124 mysqld[4294]：InnoDB：字节偏移量 0，长度 16384，i/o 类型 10。 Oct 03 22:00:46 ip-172-31-3-124 mysqld[4294]: InnoDB: 如果您在 mysqld 启动时收到此错误，请检查 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld[4294]：InnoDB：您的 my.cnf 与您在 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld[4294]：InnoDB：MySQL 服务器。 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld[4294]: 2017-10-03 22:00:46 7fe26c4fd780 InnoDB：文件 fil0fil.cc 行 5601 中的线程 140610456508288 中的断言失败 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld[4294]：InnoDB：我们故意生成内存陷阱。 Oct 03 22:00:46 ip-172-31-3-124 mysqld[4294]: InnoDB: 向http://bugs.mysql.com提交详细的错误报告。 Oct 03 22:00:46 ip-172-31-3-124 mysqld[4294]: InnoDB: 如果你得到重复的断言失败或崩溃，甚至 Oct 03 22:00:46 ip-172-31-3-124 mysqld[4294]: InnoDB: mysqld 启动后，可能有 Oct 03 22:00:46 ip-172-31-3-124 mysqld[4294]: InnoDB: InnoDB 表空间损坏。请参阅 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld[4294]: InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld[4294]：InnoDB：关于强制恢复。 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld[4294]: 171003 22:00:46 [错误] mysqld 得到信号 6； 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld[4294]：这可能是因为您遇到了错误。这个二进制文件也有可能 Oct 03 22:00:46 ip-172-31-3-124 mysqld[4294]: 或者它所链接的库之一已损坏，构建不正确， 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld[4294]：或配置错误。此错误也可能是由硬件故障引起的。 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld [4294]： 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld[4294]：要报告此错误，请参阅 https://mariadb.com/kb/en/reporting-bugs 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld [4294]： 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld[4294]：我们将尽力收集一些希望对您有所帮助的信息 Oct 03 22:00:46 ip-172-31-3-124 mysqld[4294]: 诊断问题，但由于我们已经崩溃了， 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld[4294]：肯定有问题，这可能会失败。 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld [4294]： 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld[4294]：服务器版本：10.0.31-MariaDB-0ubuntu0.16.04.2 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld[4294]: key_buffer_size=16777216 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld[4294]: read_buffer_size=131072 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld[4294]: max_used_connections=0 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld[4294]: max_threads=153 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld[4294]：thread_count=0 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld[4294]：mysqld 可能最多可以使用 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld[4294]: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 352327 K 字节内存 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld[4294]：希望没关系；如果不是，减少方程中的一些变量。 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld [4294]： 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld [4294]：线程指针：0x0 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld[4294]：尝试回溯。您可以通过以下信息了解 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld[4294]：mysqld 死的地方。如果您在此之后没有看到任何消息，则说明发生了什么事 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld[4294]：大错特错... 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld[4294]: stack_bottom = 0x0 thread_stack 0x30000 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld[4294]: /usr/sbin/mysqld(my_print_stacktrace+0x3d)[0xc1d4ad] 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld[4294]: /usr/sbin/mysqld(handle_fatal_signal+0x3bf)[0x7449df] 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld[4294]: /lib/x86_64-linux-gnu/libpthread.so.0(+0x11390)[0x7fe26b613390] 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld[4294]: /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x38)[0x7fe26abe2428] 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld[4294]: /lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7fe26abe402a] 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld[4294]: /usr/sbin/mysqld[0xab1c8b] 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld[4294]: /usr/sbin/mysqld[0xa7a4ec] 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld[4294]: /usr/sbin/mysqld[0xa7b4f4] 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld[4294]: /usr/sbin/mysqld[0xa5f4c5] 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld[4294]：/usr/sbin/mysqld[0xa236e2] 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld[4294]: /usr/sbin/mysqld[0xa17fad] 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld[4294]: /usr/sbin/mysqld[0xa18b2d] 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld[4294]: /usr/sbin/mysqld[0xa1997e] 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld[4294]: /usr/sbin/mysqld[0xa03d28] 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld[4294]: /usr/sbin/mysqld[0x9364c5] 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld[4294]: /usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x5e)[0x746ade] 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld[4294]: /usr/sbin/mysqld[0x5d7f15] 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld[4294]: /usr/sbin/mysqld(_Z11plugin_initPiPPci+0x530)[0x5d8600] 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld[4294]: /usr/sbin/mysqld[0x528c13] 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld[4294]: /usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x570)[0x52ea30] 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld[4294]: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7fe26abcd830] 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld[4294]: /usr/sbin/mysqld(_start+0x29)[0x523f09] 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld[4294]：http://dev.mysql.com/doc/mysql/en/crashing.html 的手册页包含 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld[4294]：可以帮助您找出导致崩溃的原因的信息。 10 月 3 日 22:00:46 ip-172-31-3-124 mysqld_safe[4311]: 来自 pid 文件 /var/run/mysqld/mysqld.pid 的 mysqld 结束 10 月 3 日 22:01:17 ip-172-31-3-124 /etc/init.d/mysql[4590]: 0 个进程活着并且 '/usr/bin/mysqladmin --defaults-file=/etc/mysql/ debian.cnf ping'导致 10 月 3 日 22:01:17 ip-172-31-3-124 /etc/init.d/mysql[4590]:[61B blob 数据] Oct 03 22:01:17 ip-172-31-3-124 /etc/init.d/mysql[4590]: error: 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld .sock' (2 "没有这样的文件或目录")'

系统是 Ubuntu 16.04。

我备份了数据库文件并添加了：

[mysqld] innodb_force_recovery=6

我仍然无法启动 mysql。

有什么建议吗？

【问题讨论】：

我的情况和你一样，每次电源意外断电时，我的 mariadb/innodb 表都会损坏。这首先不应该发生，但我无法自动恢复的事实让我认为 mariadb/innodb 是真正的垃圾软件。我的表中没有任何珍贵的东西，它只是在记录大部分无用的东西，我真的不能为如此无价值的数据浪费这么多时间！

【参考方案1】：

来自 MySQL 自己的页面： Forcing InnoDB recovery

他们说不要使用大于 3 的值，因为：

如果您能够以小于等于 3 的 innodb_force_recovery 值转储您的表，那么您相对安全，只有损坏的单个页面上的一些数据会丢失。 4 或更大的值被认为是危险的，因为数据文件可能会永久损坏。值 6 被认为是严重的，因为数据库页面处于过时状态，这反过来可能会给 B 树和其他数据库结构带来更多损坏。

不幸的是，InnoDB 的 my.cnf 值似乎是正确的（这曾经让我遇到了麻烦）。

我不想将其作为官方答案，但您可能需要在某些关键文件损坏之前找到备份。

InnoDB 文件不像 ISAM，你不能只是重新创建表，然后用你拥有的副本覆盖文件。很多信息都保存在地址为innodb_data_file_path 的文件中。

如果您有 innodb_file_per_table 并且不存在备份，那么您可能必须“重新安装”mysql 并重新创建数据库并从您拥有的当前文件备份中移动表并使用此过程恢复。这个我用过一次。

InnoDB lost table but file exists