完美解决mysql启动后随即关闭的问题(ibdata1文件损坏导致)

 更新时间:2017年03月27日 11:10:58   投稿:jingxian  
下面小编就为大家带来一篇完美解决mysql启动后随即关闭的问题(ibdata1文件损坏导致)。小编觉得挺不错的,现在就分享给大家,也给大家做个参考。一起跟随小编过来看看吧

机房一台服务器上的mysql运行一段时间了,突然出现了一个很奇怪的现象:重启后无法恢复了!准确情况是:启动mysql后随即就又关闭了。

查看mysql错误日志如下:

160920 22:41:41 mysqld_safe Starting mysqld daemon with databases from /home/MysqlData/
2016-09-20 22:41:41 0 [Note] /Data/app/mysql5.6.25/bin/mysqld (mysqld 5.6.25-log) starting as process 32372 ...
2016-09-20 22:41:42 32372 [Note] Plugin 'FEDERATED' is disabled.
2016-09-20 22:41:42 32372 [Warning] option 'innodb-write-io-threads': unsigned value 1000 adjusted to 64
2016-09-20 22:41:42 32372 [Warning] option 'innodb-read-io-threads': unsigned value 1000 adjusted to 64
2016-09-20 22:41:42 32372 [Note] InnoDB: Using atomics to ref count buffer pool pages
2016-09-20 22:41:42 32372 [Note] InnoDB: The InnoDB memory heap is disabled
2016-09-20 22:41:42 32372 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2016-09-20 22:41:42 32372 [Note] InnoDB: Memory barrier is not used
2016-09-20 22:41:42 32372 [Note] InnoDB: Compressed tables use zlib 1.2.3
2016-09-20 22:41:42 32372 [Note] InnoDB: Using CPU crc32 instructions
2016-09-20 22:41:42 32372 [Note] InnoDB: Initializing buffer pool, size = 1.0G
2016-09-20 22:41:42 32372 [Note] InnoDB: Completed initialization of buffer pool
2016-09-20 22:41:42 32372 [Note] InnoDB: Highest supported file format is Barracuda.
2016-09-20 22:41:42 32372 [Note] InnoDB: Log scan progressed past the checkpoint lsn 20293587957
2016-09-20 22:41:42 32372 [Note] InnoDB: Database was not shutdown normally!
2016-09-20 22:41:42 32372 [Note] InnoDB: Starting crash recovery.
2016-09-20 22:41:42 32372 [Note] InnoDB: Reading tablespace information from the .ibd files...
2016-09-20 22:41:42 32372 [Note] InnoDB: Restoring possible half-written data pages
2016-09-20 22:41:42 32372 [Note] InnoDB: from the doublewrite buffer...
InnoDB: Doing recovery: scanned up to log sequence number 20293596130
2016-09-20 22:41:42 32372 [Note] InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 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 136254, file name mysql-bin.000013
2016-09-20 22:41:43 32372 [Note] InnoDB: 128 rollback segment(s) are active.
2016-09-20 22:41:43 32372 [Note] InnoDB: Waiting for purge to start
2016-09-20 22:41:43 7f77a9edd700 InnoDB: Assertion failure in thread 140151928772352 in file trx0purge.cc line 699
InnoDB: Failing assertion: purge_sys->iter.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.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
02:41:43 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.

分析日志后发现,数据库无法重启的原因是因为ibdata1文件损坏,重启后无法正常恢复。

解决办法:

需要跳过恢复步骤,修改my.cnf文件,在my.cnf中的[mysqld]中添加:

innodb_force_recovery = 6
innodb_purge_threads = 1

解释:

innodb_force_recovery可以设置为1-6,大的数字包含前面所有数字的影响。

具体数字对应的含义:

1-----(SRVFORCEIGNORECORRUPT):忽略检查到的corrupt页。
2-----(SRVFORCENOBACKGROUND):阻止主线程的运行,如主线程需要执行full purge操作,会导致crash。
3-----(SRVFORCENOTRXUNDO):不执行事务回滚操作。
4-----(SRVFORCENOIBUFMERGE):不执行插入缓冲的合并操作。
5-----(SRVFORCENOUNDOLOGSCAN):不查看重做日志,InnoDB存储引擎会将未提交的事务视为已提交。
6-----(SRVFORCENOLOG_REDO):不执行前滚的操作。

再次启动mysql就ok了~

如果还无法启动,则需要删除数据目录datafile下的 ibdata1,ib_logfile*等文件。

启动后导出MySQL数据库,重新恢复即可。

以上这篇完美解决mysql启动后随即关闭的问题(ibdata1文件损坏导致)就是小编分享给大家的全部内容了,希望能给大家一个参考,也希望大家多多支持脚本之家。

相关文章

  • Mysql数据类型与CRUD操作详细讲解

    Mysql数据类型与CRUD操作详细讲解

    这篇文章主要介绍了Mysql数据类型与CRUD操作,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习吧
    2022-10-10
  • CentOS6.9+Mysql5.7.18源码安装详细教程

    CentOS6.9+Mysql5.7.18源码安装详细教程

    CentOS6.9+Mysql5.7.18源码安装,以下操作均在root用户下执行。下面通过本教程给大家详细介绍CentOS6.9+Mysql5.7.18源码安装方法,需要的的朋友参考下吧
    2017-06-06
  • 一文弄懂MySQL自增主键

    一文弄懂MySQL自增主键

    这篇文章主要介绍了MySQL自增主键,MySQL的自增主键并不一定是连续的,自增值的保存位置和修改机制决定了一种自增值不连续的场景,下面就来具体介绍一下,感兴趣的可以了解一下
    2025-01-01
  • MySQL中实现多表查询的操作方法(配sql+实操图+案例巩固 通俗易懂版)

    MySQL中实现多表查询的操作方法(配sql+实操图+案例巩固 通俗易懂版)

    本文主要讲解了MySQL中的多表查询,包括子查询、笛卡尔积、自连接、多表查询的实现方法以及多列子查询等,通过实际例子和操作,帮助读者理解如何合并多个表的数据,并进行复杂的查询操作,感兴趣的朋友一起看看吧
    2025-03-03
  • MySql用DATE_FORMAT截取DateTime字段的日期值

    MySql用DATE_FORMAT截取DateTime字段的日期值

    MySql截取DateTime字段的日期值可以使用DATE_FORMAT来格式化,使用方法如下
    2014-08-08
  • MYSQL命令行模式管理MySql的一点心得

    MYSQL命令行模式管理MySql的一点心得

    MYSQL命令行模式管理MySql的一点心得...
    2007-09-09
  • mysql清空表数据的两种方式和区别解析

    mysql清空表数据的两种方式和区别解析

    这篇文章主要介绍了mysql清空表数据的两种方式和区别,本文通过文字实例代码相结合给大家介绍的非常详细,具有一定的参考借鉴价值,需要的朋友可以参考下
    2019-05-05
  • MySQL索引优化之不适合构建索引及索引失效的几种情况详解

    MySQL索引优化之不适合构建索引及索引失效的几种情况详解

    索引是有双面性的,合理的建立索引可以提高数据库的效率。但是如果没有合理的构建索引和使用索引,可能会导致索引失效或者影响数据库性能,本文主要讨论的是索引失效以及不适合建立索引的场景
    2022-07-07
  • 揭开SQL中NULL的神秘面纱

    揭开SQL中NULL的神秘面纱

    表的字段默认允许存放NULL值,这意味着,您在插入记录或者更新记录时,可以不为该字段指定值,此时该字段将存储NULL值,这篇文章将揭开SQL中NULL的神秘面纱。这个问题可能困扰着很多初级开发者
    2023-01-01
  • mysql日期函数用法大全

    mysql日期函数用法大全

    日期函数在实际应用中可以帮助你轻松处理和操作日期时间数据,使得数据库操作更为灵活和便捷,本文主要介绍了mysql日期函数用法大全,感兴趣的可以了解一下
    2024-05-05

最新评论