InnoDb什么情况会运行运行着突然崩溃？或者调节什么参数能避免这种情况发生？

数据库在大数据量一直插入的情况下，运行运行着就会崩溃，没有任何断电重启情况发生
mysql版本：5.0.51a-24+lenny4-log (Debian)
在重启的时候的系统日志：
Mar 27 10:56:11 guoyu mysqld[17844]: InnoDB: Starting in background the rollback of uncommitted transactions
Mar 27 10:56:11 guoyu mysqld[17844]: 110327 10:56:11  InnoDB: Rolling back trx with id 0 30815236, 257786 rows to undo
Mar 27 10:56:11 guoyu mysqld[17844]:
Mar 27 10:56:11 guoyu mysqld[17844]: InnoDB: Progress in percents: 1110327 10:56:11  InnoDB: Error: page 1368862 log sequence number 31 4201759599
Mar 27 10:56:11 guoyu mysqld[17844]: InnoDB: is in the future! Current system log sequence number 0 8214.
Mar 27 10:56:11 guoyu mysqld[17844]: InnoDB: Your database may be corrupt or you may have copied the InnoDB
Mar 27 10:56:11 guoyu mysqld[17844]: InnoDB: tablespace but not the InnoDB log files. See
Mar 27 10:56:11 guoyu mysqld[17844]: InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
Mar 27 10:56:11 guoyu mysqld[17844]: InnoDB: for more information.
Mar 27 10:56:11 guoyu mysqld[17844]: 110327 10:56:11  InnoDB: Error: page 31286 log sequence number 0 1407651
Mar 27 10:56:11 guoyu mysqld[17844]: InnoDB: is in the future! Current system log sequence number 0 8214.
Mar 27 10:56:11 guoyu mysqld[17844]: InnoDB: Your database may be corrupt or you may have copied the InnoDB
Mar 27 10:56:11 guoyu mysqld[17844]: InnoDB: tablespace but not the InnoDB log files. See
Mar 27 10:56:11 guoyu mysqld[17844]: InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
Mar 27 10:56:11 guoyu mysqld[17844]: InnoDB: for more information.
Mar 27 10:56:11 guoyu mysqld[17844]: 110327 10:56:11  InnoDB: Error: page 1359872 log sequence number 0 3866035
Mar 27 10:56:11 guoyu mysqld[17844]: InnoDB: is in the future! Current system log sequence number 0 8214.
Mar 27 10:56:11 guoyu mysqld[17844]: InnoDB: Your database may be corrupt or you may have copied the InnoDB
Mar 27 10:56:11 guoyu mysqld[17844]: InnoDB: tablespace but not the InnoDB log files. See
Mar 27 10:56:11 guoyu mysqld[17844]: InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
Mar 27 10:56:11 guoyu mysqld[17844]: InnoDB: for more information.
Mar 27 10:56:11 guoyu mysqld[17844]: InnoDB: Dump of the tablespace extent descriptor:  len 40; hex 0000000000026341ffffffff0000ffffffff000000000004aaaaaaaaaaaaaaeafeabaaaafaffffff; asc       cA                                ;
Mar 27 10:56:11 guoyu mysqld[17844]: InnoDB: Serious error! InnoDB is trying to free page 1368863
Mar 27 10:56:11 guoyu mysqld[17844]: InnoDB: though it is already ed as free in the tablespace!
Mar 27 10:56:11 guoyu mysqld[17844]: InnoDB: The tablespace free space info is corrupt.
Mar 27 10:56:11 guoyu mysqld[17844]: InnoDB: You may need to dump your InnoDB tables and recreate the whole
Mar 27 10:56:11 guoyu mysqld[17844]: InnoDB: database!
Mar 27 10:56:11 guoyu mysqld[17844]: InnoDB: Please refer to
Mar 27 10:56:11 guoyu mysqld[17844]: InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
Mar 27 10:56:11 guoyu mysqld[17844]: InnoDB: about forcing recovery.
Mar 27 10:56:11 guoyu mysqld[17844]: 110327 10:56:11InnoDB: Assertion failure in thread 2992192400 in file fsp0fsp.c line 2981
Mar 27 10:56:11 guoyu mysqld[17844]: InnoDB: We intentionally generate a memory trap.
Mar 27 10:56:11 guoyu mysqld[17844]: InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
Mar 27 10:56:11 guoyu mysqld[17844]: InnoDB: If you get repeated assertion failures or crashes, even
Mar 27 10:56:11 guoyu mysqld[17844]: InnoDB: immediately after the mysqld startup, there may be
Mar 27 10:56:11 guoyu mysqld[17844]: InnoDB: corruption in the InnoDB tablespace. Please refer to
Mar 27 10:56:11 guoyu mysqld[17844]: InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
Mar 27 10:56:11 guoyu mysqld[17844]: InnoDB: about forcing recovery.
Mar 27 10:56:11 guoyu mysqld[17844]: 110327 10:56:11 - mysqld got signal 11;
Mar 27 10:56:11 guoyu mysqld[17844]: This could be because you hit a bug. It is also possible that this binary
Mar 27 10:56:11 guoyu mysqld[17844]: or one of the libraries it was linked against is corrupt, improperly built,
Mar 27 10:56:11 guoyu mysqld[17844]: or misconfigured. This error can also be caused by malfunctioning hardware.
Mar 27 10:56:11 guoyu mysqld[17844]: We will try our best to scrape up some info that will hopefully help diagnose
Mar 27 10:56:11 guoyu mysqld[17844]: the problem, but since we have already crashed, something is definitely wrong
Mar 27 10:56:11 guoyu mysqld[17844]: and this may fail.
Mar 27 10:56:11 guoyu mysqld[17844]:
Mar 27 10:56:11 guoyu mysqld[17844]: key_buffer_size=0
Mar 27 10:56:11 guoyu mysqld[17844]: read_buffer_size=131072
Mar 27 10:56:11 guoyu mysqld[17844]: max_used_connections=0
Mar 27 10:56:11 guoyu mysqld[17844]: max_connections=10000
Mar 27 10:56:11 guoyu mysqld[17844]: threads_connected=0
Mar 27 10:56:11 guoyu mysqld[17844]: It is possible that mysqld could use up to
Mar 27 10:56:11 guoyu mysqld[17844]: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 788401 K
Mar 27 10:56:11 guoyu mysqld[17844]: bytes of memory
Mar 27 10:56:11 guoyu mysqld[17844]: Hope that's ok; if not, decrease some variables in the equation.
Mar 27 10:56:11 guoyu mysqld[17844]:
Mar 27 10:56:11 guoyu mysqld[17844]: thd=(nil)
Mar 27 10:56:11 guoyu mysqld[17844]: Attempting backtrace. You can use the following information to find out
Mar 27 10:56:11 guoyu mysqld[17844]: where mysqld died. If you see no messages after this, something went
Mar 27 10:56:11 guoyu mysqld[17844]: terribly wrong...
Mar 27 10:56:11 guoyu mysqld[17844]: Cannot determine thread, fp=0xb2592468, backtrace may not be correct.
Mar 27 10:56:11 guoyu mysqld[17844]: Stack range sanity check OK, backtrace follows:
Mar 27 10:56:11 guoyu mysqld[17844]: 0x81f3901
Mar 27 10:56:11 guoyu mysqld[17844]: 0x83e5d06
Mar 27 10:56:11 guoyu mysqld[17844]: 0x83b9c33
Mar 27 10:56:11 guoyu mysqld[17844]: 0x83be488
Mar 27 10:56:11 guoyu mysqld[17844]: 0x83ae493
Mar 27 10:56:11 guoyu mysqld[17844]: 0x83b0ae8
Mar 27 10:56:11 guoyu mysqld[17844]: 0x8373248
Mar 27 10:56:11 guoyu mysqld[17844]: 0x834f6df
Mar 27 10:56:11 guoyu mysqld[17844]: 0x83af7e0
Mar 27 10:56:11 guoyu mysqld[17844]: 0xb7f244c0
Mar 27 10:56:11 guoyu mysqld[17844]: 0xb7d3684e
Mar 27 10:56:11 guoyu mysqld[17844]: New value of fp=(nil) failed sanity check, terminating stack trace!
Mar 27 10:56:11 guoyu mysqld[17844]: Please read http://dev.mysql.com/doc/mysql/en/using-stack-trace.html and follow instructions on how to resolve the stack trace. Resolved
Mar 27 10:56:11 guoyu mysqld[17844]: stack trace is much more helpful in diagnosing the problem, so please do
Mar 27 10:56:11 guoyu mysqld[17844]: resolve it
Mar 27 10:56:11 guoyu mysqld[17844]: The manual page at http://www.mysql.com/doc/en/Crashing.html contains
Mar 27 10:56:11 guoyu mysqld[17844]: information that should help you find out what is causing the crash.
Mar 27 10:56:11 guoyu mysqld_safe[17851]: ended
Mar 27 10:56:25 guoyu /etc/init.d/mysql[18035]: 0 processes alive and '/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf ping' resulted in
Mar 27 10:56:25 guoyu /etc/init.d/mysql[18035]: ^G/usr/bin/mysqladmin: connect to server at 'localhost' failed
Mar 27 10:56:25 guoyu /etc/init.d/mysql[18035]: error: 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)'
Mar 27 10:56:25 guoyu /etc/init.d/mysql[18035]: Check that mysqld is running and that the socket: '/var/run/mysqld/mysqld.sock' exists!
Mar 27 10:56:25 guoyu /etc/init.d/mysql[18035]:
Mar 27 10:56:26 guoyu mysqld_safe[18126]: started
Mar 27 10:56:26 guoyu mysqld[18131]: InnoDB: The user has set SRV_FORCE_NO_LOG_REDO on
Mar 27 10:56:26 guoyu mysqld[18131]: InnoDB: Skipping log redo
Mar 27 10:56:26 guoyu mysqld[18131]: 110327 10:56:26  InnoDB: Started; log sequence number 0 0
Mar 27 10:56:26 guoyu mysqld[18131]: InnoDB: !!! innodb_force_recovery is set to 6 !!!
Mar 27 10:56:26 guoyu mysqld[18131]: 110327 10:56:26 [Note] /usr/sbin/mysqld: ready for connections.
Mar 27 10:56:26 guoyu mysqld[18131]: Version: '5.0.51a-24+lenny4-log'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Debian)
Mar 27 10:56:27 guoyu /etc/mysql/debian-start[18163]: Upgrading MySQL tables if necessary.
Mar 27 10:56:27 guoyu /etc/mysql/debian-start[18178]: Looking for 'mysql' in: /usr/bin/mysql
Mar 27 10:56:27 guoyu /etc/mysql/debian-start[18178]: Looking for 'mysqlcheck' in: /usr/bin/mysqlcheck
Mar 27 10:56:27 guoyu /etc/mysql/debian-start[18178]: This installation of MySQL is already upgraded to 5.0.51a, use --force if you still need to run mysql_upgrade
Mar 27 10:56:27 guoyu /etc/mysql/debian-start[18179]: Checking for insecure root accounts.
Mar 27 10:56:27 guoyu /etc/mysql/debian-start[18183]: WARNING: mysql.user contains 1 root accounts without password!
Mar 27 10:56:27 guoyu /etc/mysql/debian-start[18184]: Triggering myisam-recover for all MyISAM tables
Mar 27 10:56:28 guoyu mysqld[18131]: 110327 10:56:28 [Note] /usr/sbin/mysqld: Normal shutdown
Mar 27 10:56:28 guoyu mysqld[18131]:
Mar 27 10:56:28 guoyu mysqld[18131]: 110327 10:56:28  InnoDB: Starting shutdown...
Mar 27 10:56:30 guoyu mysqld[18131]: 110327 10:56:30  InnoDB: Shutdown completed; log sequence number 0 8204
Mar 27 10:56:30 guoyu mysqld[18131]: 110327 10:56:30 [Note] /usr/sbin/mysqld: Shutdown complete
Mar 27 10:56:30 guoyu mysqld[18131]:
Mar 27 10:56:30 guoyu mysqld_safe[18242]: ended

解决方案 »

  1.   

    InnoDb什么情况会运行运行着突然崩溃？
    原因太多
    或者调节什么参数能避免这种情况发生？1检测内存和硬盘
    2软件立马升级到5.1.55，并重新建立表空间文件。---innodb彻底重来了，令innodb用户浑身颤抖啊！
    3可以试试mysql5.5
    4表面上看表空间文件坏了，假如你的表空间文件小的话，假如不介意我们看到你的库的话，可以传到网盘，我愿意帮你看看。
    5mysql的错误信息，其实很含糊垃圾，很难让人定位哪里出错，出了什么错？
    此例谁看出了什么端倪？谈谈
      

  2.   


    删除ib_logfile也不行啊……
      

  3.   


    我觉得这个也有可能，我用的是jfs文件系统，会不会不稳定？哪种文件系统稳定性好一些呢？
      

  4.   


    谢谢您，我刚才查了查mysql的升级日志，原来一次升级能改掉那么多bug啊……回头我会尝试一下的，我看后来又出了很多个升级版本，有必要升级到那些版本吗？