每小时一个 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，然后至少这可能是一个好的备份。
还有其他想法或提示吗？
