咨询微信: dbservice1234 7 x 24 在线支持!

    你在这里

    • You are here:
    • 首页 > 博客 > PDSERVICE的博客 > MySQL错误日志中”InnoDB: Serious error! InnoDB is trying to free page though it is already marked as free in the tablespace! Assertion failure in thread in file fsp0fsp.c line mysqld got signal 11″

MySQL错误日志中”InnoDB: Serious error! InnoDB is trying to free page though it is already marked as free in the tablespace! Assertion failure in thread in file fsp0fsp.c line mysqld got signal 11″

MySQL错误日志中”InnoDB: Serious error! InnoDB is trying to free page though it is already marked as free in the tablespace! Assertion failure in thread in file fsp0fsp.c line mysqld got signal 11″

如果自己搞不定可以找诗檀软件专业MySQL数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 : 13764045638 QQ号:47079569 邮箱:service@parnassusdata.com

 

适用于:

MySQL服务器版本5.1及以上

本文档的信息适用于所有平台。

Checked for relevance on 07Feb2013

 

症状

MySQL无法以运行中InnoDB存储引擎重启,你会在MySQL错误日志中看到像这样的错误:

InnoDB: Serious error! InnoDB is trying to free page 11200

InnoDB: though it is already marked as free in the tablespa ce!

InnoDB: Assertion failure in thread 16363778 in file fsp0fsp.c line 2981

mysqld got signal 11 ;

 

页号和线程号会不同。在fsp0fsp.c源代码文件中的行可能也不同但文件相同。

 

原因

有三种可能的原因,从最可能到最不可能排序;

  • 断电和写入缓冲开启或写入缓冲控制器没有运作的备用电池的磁盘驱动。
  • 两个MySQL的备份尝试与同一InnoDB数据文件工作。
    • 显示尝试与InnoDB同时运作的两个MySQL备份的错误日志中复制启动信息和时间戳检查。锁通常恩能够避免这个情况的发生。
  • 在InnoDB插件版本中的关于blob存储的罕见错误在MySQL 5.1.51和5.7中被修复。这一系列bugs包含这些情况:Bug:11762662, Bug:11762893, Bug:11763287

 

症状是当在InnoDB日志中指示其在崩溃恢复期间空闲,它检查到一个页被标记为空闲。

 

解决方案

如果你开启服务请求,我们有可能找到一个通常不可能的造成损坏较小的方法。用你的判断力决定是否立即启动恢复或寻求帮助。

 

恢复

首先创建数据目录,所有子目录和其他MySQL备份储存数据的位置的二进制(文件复制)备份。Gzip或其他压缩能减少需要的空间。很少情况下,一个恢复方法的尝试会阻碍其他方法,而且使用这个备份时必要的。部分的恢复过程如没有执行妥当,很可能会删除数据,所以一个好的备份仍是必须的。

 

你应该使用最低可能性的innodb_force_recovery级别来重新获取你的数据,从级别2 (5.5, 5.1, 5.0, 4.0及以下)开始。如果你没有使用很高级别,这对于启动后崩溃几秒到一分钟的服务器来说很正常,所以在你能访问服务器后尝试更多工作之前等待60秒。不要担心崩溃,它是因为后台清理,回滚,插入缓冲合并或撤销日志扫描任务的行为。只要转移到下一个级别。一旦能访问时间,继续以下步骤:

 

  1. 使用以下方法之一创建数据备份:
  2. 使用ALTER TABLE来讲所有InnoDB表转换为MyISAM。如果你在使用innodb_file_per_table,这个方法的磁盘使用空间最低并且通常会在工作时释放空间。如果需要的话,你也能说出索引来减少磁盘空间使用,但注意删除的是哪个,因为你需要之后再重建它们。
  3. 使用mysqldump程序来创建所有InnoDB表(5.5, 5.1, 5.0. 4.1及以下)的备份。一旦创建了备份,使用DROP TABLE来删除它们。
  4. 对于这部分的恢复,不要使用备份方法如InnoDB热备份或创建二进制副本的MySQL企业版备份。这些会复制将数据与错误一起复制。这是之前创建的二进制文件备份的附加。如果你没有两个备份的空间,你可能需要删除初始二进制副本来完成第一步。
  5. 如果INFORMATION_SCHEMA存在于你的MySQL版本,使用SELECT from INFORMATION_SCHEMA来确保所有表被转换,否则使用SHOW TABLES和操作系统搜索子目录中的*.ibd。留在InnoDB中的任何数据都将在下一步丢失,因此执行彻底检查是至关重要的。
  6. 删除所有遗留的InnoDB文件,ib_logfile *和ibdata *。这将删除在服务器中的所有InnoDB数据,失去尚未备份或转换为MyISAM的任何数据。请务必在执行之前认真检查你的备份或表转换为MyISAM。
  7. 重启MySQL,它会创造新的,空的,InnoDB文件。
  8. 或者使用ALTER TABLE从MyISAM转换回InnoDB,或重新加载mysqldump备份文件。一旦完成这个操作,你的服务器应该恢复正常。如果你删除索引来释放磁盘空间,现在将它们重新添加。

 

防止今后此类事件的发生

确保用于存储数据,在所有硬盘驱动的写缓冲被关闭。

确保任何写入缓存磁盘控制器有一个备用电池。

If you are affected by the blob bug, upgrade to MySQL 5.1.51 or 5.5.7 or later. 如果你受blob bug的影响,升级到MySQL 5.1.51或5.5.7或更高版本。