Flashcache bypass: disabled Flashcache setup error is : ioctl failed 解决办法

爱被打了一巴掌 2022-02-25 10:42 232阅读 0赞

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][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][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][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][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.

[http_bugs.mysql.com_bug.php_id_60895]: http://bugs.mysql.com/bug.php?id=60895
[http_dev.mysql.com_doc_refman_5.5_en_forcing-innodb-recovery.html]: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
[http_bugs.mysql.com]: http://bugs.mysql.com