table_log,innodb表,有一个存储过程abc,用于从table_log表中读取数据,自服务器启动开始,就有一个程序往table_log中insert数据,但并不是一直lock这个表,就是断断续续的insert,从Apache日志中看,abc被服务器运行时,经常是“Deadlock found when trying to get lock; try restarting transaction”,在重复了大概7、8次左右,突然就“query error[2010-12-08 15:32:01][../dbClient/MySqlDatabase.cpp:165] Can't connect to local MySQL server through socket '/tmp/mysql.sock'”了,然后,Apache日志中断了50分钟没有没有任何记录,从系统日志syslog上看,在出现这个问题的时候,没有任何错误信息,还在一直运行着各种脚本,而就在50分钟后Apache日志有信息的同时(当然,这时候还是一堆的“ Can't connect to local MySQL server through socket '/tmp/mysql.sock”),系统日志就出现了这样的信息:
Dec 8 15:31:58 abc mysqld[2687]: InnoDB: Database page corruption on disk or a failed
Dec 8 15:31:58 abc mysqld[2687]: InnoDB: file read of page 83999.
Dec 8 15:31:58 abc mysqld[2687]: InnoDB: You may have to recover from a backup.
Dec 8 15:31:58 abc mysqld[2687]: 101208 15:31:58 InnoDB: Page dump in ascii and hex (16384 bytes):
Dec 8 15:31:58 abc mysqld[2687]: len 16384; hex 85f7c6c900。。一堆dump码之后,force_recovery=1,select * into outfile,drop掉这个表,重建这个表,导入数据,修复了,期间看不出有任何重启或者拔电的迹象,这个问题能是因为什么呢?磁盘就因为几次死锁,就挂掉了???
Dec 8 15:31:58 abc mysqld[2687]: InnoDB: Database page corruption on disk or a failed
Dec 8 15:31:58 abc mysqld[2687]: InnoDB: file read of page 83999.
Dec 8 15:31:58 abc mysqld[2687]: InnoDB: You may have to recover from a backup.
Dec 8 15:31:58 abc mysqld[2687]: 101208 15:31:58 InnoDB: Page dump in ascii and hex (16384 bytes):
Dec 8 15:31:58 abc mysqld[2687]: len 16384; hex 85f7c6c900。。一堆dump码之后,force_recovery=1,select * into outfile,drop掉这个表,重建这个表,导入数据,修复了,期间看不出有任何重启或者拔电的迹象,这个问题能是因为什么呢?磁盘就因为几次死锁,就挂掉了???
我也是一知半解,但现象确实如此…
似乎确实可以考虑考虑MYISAM,不过这个文件碎片怕在大量的插入和删除之后变得很客观啊,我这个表是不打算随便就optimize table的,因为是有很多很大的表,而且这个操作耗时应该不小吧…
用的Linux系统是gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) i686 GNU/Linux
文件系统是JFS
而不是人去innodb_force_recovery=xxx的,然后做一堆操作?