[转]解决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
竟然提示内存不足以分配,暂时释放了一下内存,重新重启,终于正常了。接下来要查哪里内存使用出现问题了。

posted on   范兵  阅读(978)  评论(0编辑  收藏  举报

编辑推荐:
· 开发者必知的日志记录最佳实践
· SQL Server 2025 AI相关能力初探
· Linux系列:如何用 C#调用 C方法造成内存泄露
· AI与.NET技术实操系列(二):开始使用ML.NET
· 记一次.NET内存居高不下排查解决与启示
阅读排行:
· Manus重磅发布:全球首款通用AI代理技术深度解析与实战指南
· 被坑几百块钱后,我竟然真的恢复了删除的微信聊天记录!
· 没有Manus邀请码?试试免邀请码的MGX或者开源的OpenManus吧
· 园子的第一款AI主题卫衣上架——"HELLO! HOW CAN I ASSIST YOU TODAY
· 【自荐】一款简洁、开源的在线白板工具 Drawnix

导航

< 2025年3月 >
23 24 25 26 27 28 1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31 1 2 3 4 5
点击右上角即可分享
微信分享提示