主页 / server / 问题 / 1122389
Accepted
Eugene van der Merwe
Asked: 2023-02-10 01:19:52 +0800 CST

InnoDB：文件断言失败 .../padding_for_CPACK_RPM_BUILD_SOURCE_DIRS_PREFIX/mariadb-10.4.13/storage/innobase/btr/btr0cur.cc 第 7940 行

  • 772

每小时一个 MariaDB 10.4 版数据库停止响应，我在日志文件中看到以下输出：

Feb  9 10:00:02 maria55 mysqld: 2023-02-09 10:00:02 0x7f72547a5700  InnoDB: Assertion failure in file /home/buildbot/buildbot/padding_for_CPACK_RPM_BUILD_SOURCE_DIRS_PREFIX/mariadb-10.4.13/storage/innobase/btr/btr0cur.cc line 7940
Feb  9 10:00:02 maria55 mysqld: InnoDB: Failing assertion: space_id == page_get_space_id(page)
Feb  9 10:00:02 maria55 mysqld: InnoDB: We intentionally generate a memory trap.
Feb  9 10:00:02 maria55 mysqld: InnoDB: Submit a detailed bug report to https://jira.mariadb.org/
Feb  9 10:00:02 maria55 mysqld: InnoDB: If you get repeated assertion failures or crashes, even
Feb  9 10:00:02 maria55 mysqld: InnoDB: immediately after the mysqld startup, there may be
Feb  9 10:00:02 maria55 mysqld: InnoDB: corruption in the InnoDB tablespace. Please refer to
Feb  9 10:00:02 maria55 mysqld: InnoDB: https://mariadb.com/kb/en/library/innodb-recovery-modes/
Feb  9 10:00:02 maria55 mysqld: InnoDB: about forcing recovery.

服务器正在运行 Kopano，虽然我找不到任何导致这个问题的突出 CRON 正好在一个小时内，但我完全怀疑 Kopano 每小时都有一些维护例程触发崩溃。

关于 InnoDB 腐败的建议听起来很合理，但我不知道该怎么做，链接不明确。

现在我们做了一个mysqlcheck kopano数据库检查工作 100%

进一步谷歌搜索并没有真正显示任何东西。

我不知道接下来要尝试什么。

我的一个想法是升级数据库以查看是否有任何“错误”可能被压缩，但是当我们转储到同一磁盘时，发生了这种情况：

mysqldump --single-transaction --routines kopano -r kopanodb.sql

mysqldump: Error 2013: Lost connection to MySQL server during query when dumping table 'lob' at row: 166961

现在我有一个次要问题，我无法进行备份。数据库的总大小是80GB！

我的想法是升级 MariaDB，但现在我害怕事情会出现灾难性的错误，我不会有一个好的备份。

我的另一个想法是停止 MariaDB 服务，然后复制/var/lib/mysql到一个临时位置，全部 80 GB，然后至少这可能是一个好的备份。

还有其他想法或提示吗？

mysql

1 个回答

  1. Best Answer

    解决方案是升级 MariaDB。线索是 MariaDB 的 10.4 版本很旧，这一行：

    提交详细的错误报告...

    为了解决数据库备份的问题，我通过停止服务使数据库脱机，然后只复制了一个目录/文件。这不是一个理想的备份，但我认为如果出现问题我可以恢复。

    • 0

相关问题