Flashcache bypass:disabled Flashcache Setup Error Is:ioctl failed solution

MySQL Batch execute INSERT statement when MySQL suddenly shutdown, restart MySQL when the information in the log is as follows:

MySQL version: Server version:5.5.13-rel20.4-log Percona server with XTRADB (GPL), release rel20.4, Revision 138

Find this on the official web side is a bug specific information: http://bugs.mysql.com/bug.php?id=60895

The reason is:

A bug that triggers a file page being reused because a new version is generated when the data is Dump/load

Solution:

/ETC/MY.CNF in configuration file

Add 2 lines:

Innodb_force_recovery = 3

--3 (Srv_force_no_trx_undo): Do not perform transaction rollback operation.

Innodb_purge_thread = 0
--when innodb_force_recovery>2 can lead to infinite loop

Note: The disadvantage of this approach is that some data in the database is inaccurate because the previous transaction does not perform a rollback operation.

Database to Mysqlchek each table, the problem of the table to rebuild;

Then the
Innodb_force_recovery

Innodb_purge_thread

The best case:

Comment out, restart the database, the database is working correctly.

Innodb_force_recovery > 0 Database cannot perform DML operation

Medium Condition:

Locate the problem database backup database, delete the database, change back the parameters, restart the database

And then lead back the data.

In the worst case scenario, the Innodb_force_recovery is set to 0

The database will not be able to start deleting the dead table (or even deleting the database and having to back it up before deleting it) is useless.

The steps to be processed at this time:

1. For small database is not prepared in case, directly in the case of innodb_force_recovery = 3 to backup the database, and then reload the database, restore the database.

2. For the medium-sized database has the main standby, the main standby switch, and then the Dead master, to reload, and then the main when the machine.

3. For large databases, do cluster, there will be no innodb problems.

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 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 is 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 is 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 A 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 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 and 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 spaces 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 on file fsp0fsp.c line 3360
Innodb:we intentionally generate a memory trap.
Innodb:submit a detailed bug to http://bugs.mysql.com.
Innodb:if you get repeated assertion failures or crashes, even
Innodb:immediately after the mysqld startup, there may
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 is because you hit a bug. It is also possible the this binary
Or one of the libraries it is corrupt against, improperly built,
Or misconfigured. This error can also is caused by malfunctioning hardware.
We'll try our best to scrape up some info that'll hopefully help diagnose
The problem, but since we have already crashed, something is definitely wrong
And this may fail.