昨天上午mysql又碰到一个奇怪的问题。数据库异常终止。重启成功后过就马上崩溃，不能正常运行。
查看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 -uroot -p123456 -R gamedb > /data/backup/gamedb.sql
3、删除数据库gamedb或者移到备份目录下面，然后一定要重新初始化数据库，否则数据恢复了错误日志里也会提示表空间没有日志文件，数据库也会不断重启。
4、启动mysql服务，导入数据
mysql> create database gamedb default character set utf8;
mysql> user gamedb
mysql> source /data/backup/gamedb.sql
5、程序和数据库运行正常。
严重怀疑5.5.21版本有bug，我已经碰到两次了，一次wait IO高（http://blog.csdn.net/thomas0yang/article/details/8099515），这次又不能正常启动。
请问谁有类似经历，或者帮我解惑呢？
不行降低版本了。。。