我有 xen 虚拟机(Debian 在 PV 模式下稳定)并且我在上面有 Joomla。我一天中多次在网站首页上看到此消息。
jtablesession::Store Failed
DB function failed with error number 144
Table './database@002enet/hfd_session' is marked as crashed and last (automatic?) repair failed SQL=INSERT INTO `hfd_session`
( `session_id`,`time`,`username`,`gid`,`guest`,`client_id` ) VALUES ( 'iae9qhmfhst464v4d0a6ho6nt3','1330628728','','0','1','0' )
我找不到它崩溃的原因。
mysql.log和mysql.err日志清晰。 mysql慢日志中只有一些记录,但它们似乎与这张表没有联系。只有这张桌子崩溃了。
我尝试删除该表并再次创建它,重新启动系统并使用 fsck 检查磁盘(没有错误)。但我仍然遇到这个崩溃,每次看到它时我都需要手动修复它。
有什么办法可以解决这个问题吗?
$ dpkg -l | grep mysql
ii libdbd-mysql-perl 4.016-1 Perl5 database interface to the MySQL database
ii libmysqlclient16 5.1.49-3 MySQL database client library
ii mysql-client-5.1 5.1.49-3 MySQL database client binaries
ii mysql-common 5.1.49-3 MySQL database common files, e.g. /etc/mysql/my.cnf
ii mysql-server 5.1.49-3 MySQL database server (metapackage depending on the latest version)
ii mysql-server-5.1 5.1.49-3 MySQL database server binaries and system database setup
ii mysql-server-core-5.1 5.1.49-3 MySQL database server binaries
ii php5-mysql 5.3.3-7+squeeze3 MySQL module for php5
答案1
我们经常处理崩溃的 mysql 表,因此很少有关于尝试的建议。
首先,尝试删除表,重新启动 mysql,然后重新添加表。这将让它完全重新创建表并修复任何潜在的结构错误。另外,修复表后跟flush_tables也可以工作,但我们发现它的成功率不高。
如果这不起作用,请尝试将表移至完全位于内存中的表。从 InnoDB 或 MyISM 切换到 MEMORY,看看是否仍然崩溃。请注意,该表不会在重新启动后保留结果,但由于它是会话表,因此不会影响您。这样做的原因是,当系统/数据库检查点发生时,较慢的磁盘会产生大量查询,例如损坏表。我还没有看到这方面的完整关联,但在每种情况下,较快的服务器出错的次数都不会接近较慢的服务器出错的次数。鉴于这是一个虚拟机,磁盘缓慢有时可能会成为一个问题。
最后一件事是启用完整的 mysql 查询日志。这将要影响性能,所以要小心。这里的想法是跟踪哪个查询最后成功,哪个查询失败。如果你发现了足够多的失败,你就会发现一种模式。如果您能够可靠地重现崩溃,那么您就遇到了 MySQL 错误。希望你不会达到这一点:)
答案2
repair table [name of crashed table]