Flashcache bypass: disabled Flashcache setup error is : ioctl failed 解决办法
mysql批量执行insert 语句的时候 mysql突然shutdown ，再次重启mysql的时候 日志里面的信息如下：
mysql版本 ： Server version: 5.5.13-rel20.4-log Percona Server with XtraDB (GPL), Release rel20.4, Revision 138
在官网上面查找到 这个是一个bug 具体信息： http://bugs.mysql.com/bug.php?id=60895
原因是：
由于dump / load数据的时候产生新的版本，导致文件页被重用触发的bug
解决办法：
在配置文件中 /etc/my.cnf
加上2行：
innodb_force_recovery = 3
-- 3(SRV_FORCE_NO_TRX_UNDO):不执行事务回滚操作。
innodb_purge_thread = 0
-- 当innodb_force_recovery>2的时候 可能会导致无限的LOOP
注意： 这种办法的缺点是数据库某些数据不准确，因为之前的事务不执行回滚操作。
逐个数据库去mysqlchek 各个表，将有问题的表进行重建；
然后将
innodb_force_recovery
innodb_purge_thread
最好的情况：
注释掉，重启数据库，数据库正常工作。
innodb_force_recovery > 0 数据库则无法进行 dml操作
中等情况：
定位出问题的数据库 备份数据库，删除数据库，改回参数，重启数据库
然后导回数据。
最坏的情况是 ，innodb_force_recovery设置为0
数据库就无法启动 将坏死的表删掉（甚至数据库删掉，删掉之前必须备份）也无济于事。
这时候要处理的步骤：
1.对于小型数据库没有做主备的情况下， 直接在innodb_force_recovery = 3的情况下 将数据库备份出来，然后重装数据库，还原数据库。
2.对于中型数据库有主备的 ，主备切换，然后将坏死的主，进行重装，然后主当从机。
3.对于大型数据库，做了cluster的 ，不会有innodb的问题。
130507 14:01:15 mysqld_safe Starting mysqld daemon with databases from /opt/mysql/data
130507 14:01:15 [Warning] option 'slow_query_log': boolean value '/opt/mysql/log/slow.log' wasn't recognized. Set to OFF.
130507 14:01:15 [Note] Flashcache bypass: disabled
130507 14:01:15 [Note] Flashcache setup error is : ioctl failed
130507 14:01:15 [Note] Plugin 'FEDERATED' is disabled.
130507 14:01:15 [Warning] option 'innodb-additional-mem-pool-size': signed value 200 adjusted to 524288
130507 14:01:15 InnoDB: The InnoDB memory heap is disabled
130507 14:01:15 InnoDB: Mutexes and rw_locks use GCC atomic builtins
130507 14:01:15 InnoDB: Compressed tables use zlib 1.2.3
130507 14:01:15 InnoDB: Using Linux native AIO
130507 14:01:15 InnoDB: Initializing buffer pool, size = 16.0G
130507 14:01:17 InnoDB: Completed initialization of buffer pool
130507 14:01:17 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 2325170411593
130507 14:01:17 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 2325175654400
InnoDB: Doing recovery: scanned up to log sequence number 2325180897280
InnoDB: Doing recovery: scanned up to log sequence number 2325186140160
InnoDB: Doing recovery: scanned up to log sequence number 2325191383040
InnoDB: Doing recovery: scanned up to log sequence number 2325196625920
InnoDB: Doing recovery: scanned up to log sequence number 2325201868800
InnoDB: Doing recovery: scanned up to log sequence number 2325207111680
InnoDB: Doing recovery: scanned up to log sequence number 2325212354560
InnoDB: Doing recovery: scanned up to log sequence number 2325217597440
InnoDB: Doing recovery: scanned up to log sequence number 2325222840320
InnoDB: Doing recovery: scanned up to log sequence number 2325228083200
InnoDB: Doing recovery: scanned up to log sequence number 2325233326080
InnoDB: Doing recovery: scanned up to log sequence number 2325238568960
InnoDB: Doing recovery: scanned up to log sequence number 2325243811840
InnoDB: Doing recovery: scanned up to log sequence number 2325249054720
InnoDB: Doing recovery: scanned up to log sequence number 2325254297600
InnoDB: Doing recovery: scanned up to log sequence number 2325259540480
InnoDB: Doing recovery: scanned up to log sequence number 2325264783360
InnoDB: Doing recovery: scanned up to log sequence number 2325270026240
InnoDB: Doing recovery: scanned up to log sequence number 2325275269120
InnoDB: Doing recovery: scanned up to log sequence number 2325278797392
InnoDB: 1 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 27584585 row operations to undo
InnoDB: Trx id counter is 14F00
130507 14:01:33 InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 10 11 12 13 14 15 16 17 18 19 20 21 22 23 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
InnoDB: Last MySQL binlog file position 0 479663790, file name /opt/mysql/log/mysql-bin.000392
InnoDB: Starting in background the rollback of uncommitted transactions
130507 14:01:44 InnoDB: Rolling back trx with id 14B7D, 27584585 rows to undo
InnoDB: Progress in percents: 1130507 14:01:44 InnoDB: Waiting for the background threads to start
InnoDB: Dump of the tablespace extent descriptor: len 40; hex 00000000000000020004c00019c6000780001b2e00000001ffffffffffffffffffffffffffffffff; asc
. ;
InnoDB: Serious error! InnoDB is trying to free page 321727
InnoDB: though it is already marked as free in the tablespace!
InnoDB: The tablespace free space info is corrupt.
InnoDB: You may need to dump your InnoDB tables and recreate the whole
InnoDB: database!
InnoDB: Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
130507 14:01:45 InnoDB: Assertion failure in thread 1201330496 in file fsp0fsp.c line 3360
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.
130507 14:01:45 - 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.