解决Mysql InnoDB: Failing assertion: ret || !assert_on_error问题

国庆回来后,发现mysql停止服务了,没办法继续启动了。查看日志,看到:

131008 09:56:03 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
131008  9:56:03 [Warning] option 'read_buffer_size': unsigned value 1024 adjusted to 8192
131008  9:56:03 [Note] Plugin 'FEDERATED' is disabled.
131008  9:56:03 InnoDB: The InnoDB memory heap is disabled
131008  9:56:03 InnoDB: Mutexes and rw_locks use GCC atomic builtins
131008  9:56:03 InnoDB: Compressed tables use zlib 1.2.3
131008  9:56:03 InnoDB: Using Linux native AIO
131008  9:56:03 InnoDB: Initializing buffer pool, size = 128.0M
131008  9:56:03  InnoDB: Assertion failure in thread 47953380146304 in file ut0mem.c line 103
InnoDB: Failing assertion: ret || !assert_on_error
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.
01:56:03 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.
 
key_buffer_size=0
read_buffer_size=8192
max_used_connections=0
max_threads=151
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 312196 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
 
Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0 thread_stack 0x40000
/usr/libexec/mysqld(my_print_stacktrace+0x2e)[0x78b18e]
/usr/libexec/mysqld(handle_fatal_signal+0x493)[0x6741b3]
/lib64/libpthread.so.0(+0xf500)[0x2b9d0116a500]
/lib64/libc.so.6(gsignal+0x35)[0x2b9d02b9f8a5]
/lib64/libc.so.6(abort+0x175)[0x2b9d02ba1085]
/usr/libexec/mysqld[0x8363d8]
/usr/libexec/mysqld[0x8944be]
/usr/libexec/mysqld[0x893d26]
/usr/libexec/mysqld[0x84ea80]
/usr/libexec/mysqld[0x858aab]
/usr/libexec/mysqld[0x817bf0]
/usr/libexec/mysqld[0x7e4390]
/usr/libexec/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x41)[0x676eb1]
/usr/libexec/mysqld[0x58d4d8]
/usr/libexec/mysqld(_Z11plugin_initPiPPci+0x8c8)[0x590db8]
/usr/libexec/mysqld[0x518078]
/usr/libexec/mysqld(_Z11mysqld_mainiPPc+0x3fd)[0x51b1dd]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x2b9d02b8bcdd]
/usr/libexec/mysqld[0x510ee5]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
131008 09:56:03 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended

根据这个链接:

http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html,进行操作,修改my.cnf,加入:

[mysqld]
innodb_force_recovery = 4
innodb_force_recovery有0 - 6,7个选项,具体含义可以直接访问上面的链接,官方解释得很清楚。

保存my.cnf后,尝试重启mysql,又出现新情况:

131008 10:00:24 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
131008 10:00:24 [Note] Plugin 'FEDERATED' is disabled.
131008 10:00:24 InnoDB: The InnoDB memory heap is disabled
131008 10:00:24 InnoDB: Mutexes and rw_locks use GCC atomic builtins
131008 10:00:24 InnoDB: Compressed tables use zlib 1.2.3
131008 10:00:24 InnoDB: Using Linux native AIO
131008 10:00:24 InnoDB: Initializing buffer pool, size = 128.0M
InnoDB: mmap(137363456 bytes) failed; errno 12
131008 10:00:24 InnoDB: Completed initialization of buffer pool
131008 10:00:24 InnoDB: Fatal error: cannot allocate memory for the buffer pool
131008 10:00:24 [ERROR] Plugin 'InnoDB' init function returned error.
131008 10:00:24 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
131008 10:00:24 [ERROR] Unknown/unsupported storage engine: InnoDB
131008 10:00:24 [ERROR] Aborting
 
131008 10:00:24 [Note] /usr/libexec/mysqld: Shutdown complete
 
131008 10:00:24 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
竟然提示内存不足以分配,暂时释放了一下内存,重新重启,终于正常了。接下来要查哪里内存使用出现问题了。

时间: 2024-10-27 22:35:22

解决Mysql InnoDB: Failing assertion: ret || !assert_on_error问题的相关文章

InnoDB: Failing assertion: trx->isolation_level == TRX_ISO_READ_UNCOMMITTED

最近再次碰到之前遇到的断言失败的bug,错误信息如下: InnoDB: Failing assertion: trx->isolation_level == TRX_ISO_READ_UNCOMMITTED   这是一个已知的bug(bug#62037),在MySQL5.5.22版本中被fix掉,在lauchpad上可以看到具体是如何修复的   如何重现 重现case,使用gdb的non-stop模式很容易重现: 启动gdb,使用non-stop set target-async 1 set p

巧用MySQL InnoDB引擎锁机制解决死锁问题

最近,在项目开发过程中,碰到了数据库死锁问题,在解决问题的过程中,笔者对MySQL InnoDB引擎锁机制的理解逐步加深. 案例如下: 在使用Show innodb status检查引擎状态时,发现了死锁问题: *** (1) TRANSACTION: TRANSACTION 0 677833455, ACTIVE 0 sec, process no 11393, OS thread id 278546 starting index read mysql tables in use 1, loc

MySQL InnoDB Replication Slave 太慢解决办法

Master 的是标? MySQL, Slave 换成 Percona, 没想到反而跟不上进度, 而且 Slave 与 Master 差距越来越远. InnoDB 效能调校文件与说明 由文件找到有个参数可以调整: innodb_flush_log_at_trx_commit 此参数调整的原因: InnoDB 预设是每次写入, 就会将 Log 写入(Flush)硬碟, 所以会很慢. innodb_flush_log_at_trx_commit 的值可以设?橄率鋈?? (预设是 1), 下述取自此篇

怎样解决MySQL 5.0.16的乱码问题

问:怎样解决MySQL 5.0.16的乱码问题? 答:MySQL 5.0.16的乱码问题可以用下面的方法解决: 1.设置phpMyAdmin Language:Chinese simplified (zh-utf-8) MySQL 字符集:UTF-8 Unicode (utf8) MySQL 连接校对 gbk_chinese_ci 2.创建数据库时 整理设置成 gbk_chinese_ci 3.用SQL建立表中 ENGINE=MyISAM DEFAULT CHARSET=gbk; ENGINE=

如何解决mysql 8小时空闲后连接超时的问题

问:怎样才能解决mysql 8小时空闲后连接超时的问题? 答:当应用程序和数据库建立连接时,如果超过了8个小时,应用程序句不会去访问数据库,数据库就会出现断掉连接的现象 .这时再次访问就会抛出异常,异常如下: Communications link failure due to underlying exception: ** BEGIN NESTED EXCEPTION ** java.io.EOFException STACKTRACE: java.io.EOFException at co

怎样才能解决MySQL 5.0.16的乱码问题

问:怎样解决MySQL 5.0.16的乱码问题? 答:MySQL 5.0.16的乱码问题可以用下面的方法解决: 1.设置phpMyAdmin Language:Chinese simplified (zh-utf-8) MySQL 字符集:UTF-8 Unicode (utf8) MySQL 连接校对 gbk_chinese_ci 2.创建数据库时 整理设置成 gbk_chinese_ci 3.用SQL建立表中 ENGINE=MyISAM DEFAULT CHARSET=gbk; ENGINE=

彻底解决mysql中文乱码的办法

MySQL会出现中文乱码的原因不外乎下列几点: 1.server本身设定问题,例如还停留在latin1 2.table的语系设定问题(包含character与collation) 3.客户端程式(例如php)的连线语系设定问题 强烈建议使用utf8!!!! utf8可以兼容世界上所有字符!!!! Linux下Mysql插入中文显示乱码解决方案 mysql -uroot -p 回车输入密码 进入mysql查看状态如下: mysql不能插入中文 默认的是客户端和服务器都用了latin1,所以会乱码.

MySQL/InnoDB和Group Commit(2)

今天发现Percona Release的Percona-Server-5-5-18-23-0已经完成了Group Commit工作,而且是用最优雅的方式(移植了MariaDB的实现,而不是workaround),心里难掩激动. 这篇文章接前篇继续介绍一下问题的背景:什么是Group Commit,现在的官方版本Group Commit做到了什么程度? 1. 什么是Group Commit MySQL/InnoDB在做事务的时候使用的日志先行(Write-ahead logging)的方式保证事务

10分钟学会理解和解决MySQL乱码问题

原文:10分钟学会理解和解决MySQL乱码问题 在阅读本文之前,强烈建议对字符集编码概念还比较模糊的同学 阅读下博主之前对相关概念的一篇科普:十分钟搞清字符集和字符编码 本博客已经迁移至: http://cenalulu.github.io/ 为了更好的体验,请通过此链接阅读: http://cenalulu.github.io/mysql/mysql-mojibake/ MySQL出现乱码的原因 要了解为什么会出现乱码,我们就先要了解从客户端发起请求,到MySQL存储数据,再到下次从表取回客户