UTC - mysqld got signal 6
昨天晚上mysql又碰到一个奇怪的问题。数据库异常终止。重启成功后过就马上崩溃，不能正常运行。
查看错误警告是
InnoDB: Doing recovery: scanned up to log sequence number 1924612226346
121103 21:29:24 InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69
70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
121103 21:29:42 InnoDB: Waiting for the background threads to start
121103 21:29:43 InnoDB: 1.1.8 started; log sequence number 1924612226346
121103 21:29:43 [Note] Event Scheduler: Loaded 0 events
121103 21:29:43 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.21-log' socket: '/var/run/mysqld/mysqld.sock' port: 3306 Source distribution
121103 21:29:44 InnoDB: Assertion failure in thread 140444553848592 in file trx0purge.c line 829
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
13:29:44 UTC - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
key_buffer_size=8388608
read_buffer_size=8388608
max_used_connections=10
max_threads=100
thread_count=10
connection_count=10
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 1238130 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0 thread_stack 0x40000
/usr/sbin/mysqld(my_print_stacktrace+0x2e)[0x76d27e]
但是内存方面配置的没有错误啊！！！
根据错误日志是没有希望了，网上查询到一片文章：http://www.2cto.com/database/201204/125762.html，跟我的情况很相似。
1、在/etc/my.cnf中写入
[mysqld] innodb_force_recovery = 4
但是仍然无法启动。
改为：innodb_force_recovery = 6
数据库可以读出来，在6的情况下，是无法修改数据库的，也无法插入，只能导出。
2、导出数据 mysqldump -uusername -ppassword databasename tablename > /home/db/db_TQ_1103.log.
3、备份空间文件、重做日志文件。删除数据库TQ。
4、启动mysql，导入数据正常。source /home/db/db_TQ_1103.log.
5、程序和数据库运行正常。
严重怀疑5.5.21版本有bug，我已经碰到两次了，一次wait IO高（http://blog.csdn.net/thomas0yang/article/details/8099515），这次又不能正常启动。
请问谁有类似经历，或者帮我解惑呢？
不行降低版本了。。。
http://dba.stackexchange.com/questions/14259/innodb-table-select-returns-error-2006-hy000-mysql-server-has-gone-away-after