mysql bug 求解

[复制链接]
查看11 | 回复9 | 2012-5-22 15:10:11 | 显示全部楼层 |阅读模式
各位,我遇到mysql bug,自己不能搞定,咨询各位dd
111125 16:15:35 InnoDB: Assertion failure in thread 1095162176 in file row/row0mysql.c line 1534
InnoDB: Failing assertion: index->type & DICT_CLUSTERED
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.1/en/forcing-recovery.html
InnoDB: about forcing recovery.
111125 16:15:35 - 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=8388608
read_buffer_size=1048576
max_used_connections=30
max_threads=1000
threads_connected=14
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 9234379 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
thd: 0xb8bf170
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 = 0x4146d100 thread_stack 0x30000
/opt/mysql/product/5.1/bin/mysqld(my_print_stacktrace+0x2e)[0x8a74ce]
/opt/mysql/product/5.1/bin/mysqld(handle_segfault+0x322)[0x5dc992]
/lib64/libpthread.so.0[0x357980eb10]
/lib64/libc.so.6(gsignal+0x35)[0x3578c30265]
/lib64/libc.so.6(abort+0x110)[0x3578c31d10]
/opt/mysql/product/5.1/bin/mysqld(row_unlock_for_mysql+0x2f2)[0x7f4a52]
/opt/mysql/product/5.1/bin/mysqld(row_search_for_mysql+0x22e1)[0x802591]
/opt/mysql/product/5.1/bin/mysqld(_ZN11ha_innobase10index_readEPhPKhj16ha_rkey_function+0x192)[0x7724d2]
/opt/mysql/product/5.1/bin/mysqld(_ZN7handler16read_range_firstEPK12st_key_rangeS2_bb+0xbe)[0x6caa9e]
/opt/mysql/product/5.1/bin/mysqld(_ZN7handler22read_multi_range_firstEPP18st_key_multi_rangeS1_jbP17st_handler_buffer+0xce)[0x6c85be]
/opt/mysql/product/5.1/bin/mysqld(_ZN18QUICK_RANGE_SELECT8get_nextEv+0x127)[0x6aa557]
/opt/mysql/product/5.1/bin/mysqld[0x6c415d]
/opt/mysql/product/5.1/bin/mysqld(_Z12mysql_deleteP3THDP10TABLE_LISTP4ItemP11st_sql_listyyb+0x86c)[0x66fc5c]
/opt/mysql/product/5.1/bin/mysqld(_Z21mysql_execute_commandP3THD+0x38bf)[0x5f03af]
/opt/mysql/product/5.1/bin/mysqld(_Z11mysql_parseP3THDPKcjPS2_+0x357)[0x5f25e7]
/opt/mysql/product/5.1/bin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0xe63)[0x5f3453]
/opt/mysql/product/5.1/bin/mysqld(_Z10do_commandP3THD+0xe6)[0x5f3d16]
/opt/mysql/product/5.1/bin/mysqld(handle_one_connection+0x236)[0x5e66d6]
/lib64/libpthread.so.0[0x357980673d]
/lib64/libc.so.6(clone+0x6d)[0x3578cd3d1d]
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x2aab4890fcd0 is an invalid pointer
thd->thread_id=62259
thd->killed=NOT_KILLED
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.
111125 16:15:35 mysqld_safe Number of processes running now: 0
111125 16:15:35 mysqld_safe mysqld restarted
InnoDB: Log scan progressed past the checkpoint lsn 0 694228728
111125 16:15:36 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 0 694229872
111125 16:15:36 InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 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 5
6 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 1397027, file name /opt/mysql/mysqldata/mysqllog/mysqlbin.000149
111125 16:15:37 InnoDB: Started; log sequence number 0 694229872
111125 16:15:37 [Note] Recovering after a crash using /opt/mysql/mysqldata/mysqllog/mysqlbin
111125 16:15:37 [Note] Starting crash recovery...
111125 16:15:37 [Note] Crash recovery finished.
复制代码
数据库版本:Server version: 5.1.35-log MySQL Community Server (GPL)
系统:Linux ezgclient 2.6.18-194.el5 #1 SMP Fri Apr 2 14:58:14 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux
请问下,这个是什么原因导致,该如何解决,在bugs.mysql.com中我查询了很久,但是没找到类此的

回复

使用道具 举报

千问 | 2012-5-22 15:10:11 | 显示全部楼层
机器内存多大呀。
回复

使用道具 举报

千问 | 2012-5-22 15:10:11 | 显示全部楼层
wlmoon 发表于 2011-11-28 17:05
机器内存多大呀。

16g的,应该不是内存原因导致的
出问题的时候,才只有14个连接
回复

使用道具 举报

千问 | 2012-5-22 15:10:11 | 显示全部楼层
mysqld got signal 6 --- 首先申明,对的错误号为6的多数问题,我还真没本事搞定,也是最复杂的....
# InnoDB: Failing assertion: index->type & DICT_CLUSTERED
# 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.
----- 从这信息看是整理簇索引,导致表空间出现损坏
# /opt/mysql/product/5.1/bin/mysqld(_Z12mysql_deleteP3THDP10TABLE_LISTP4ItemP11st_sql_listyyb+0x86c)[0x66fc5c]
# /opt/mysql/product/5.1/bin/mysqld(_Z21mysql_execute_commandP3THD+0x38bf)[0x5f03af]
---分析的情况,你的系统应该正在做一个DELETE操作,而且应该无索引可走,删除的数据量也比较大
组合上述情况及个人经验:可能是大量数据被缓存在innodb_buffer_pool_size中,并且其内部有创建自适应的hash索引,因删除数据而不得不重新创建,以及你的服务器当时IO出现瓶颈,导致一时无法响应Innodb master thread,而出现问题....并且InnoDB引擎在此方面出现过BUG,解决版本是5.1.37之后,所以建议使用:5.1.40版本,较稳定....
回复

使用道具 举报

千问 | 2012-5-22 15:10:11 | 显示全部楼层
mysqld got signal 6 --- 首先申明,对的错误号为6的多数问题,我还真没本事搞定,也是最复杂的....
# InnoDB: Failing assertion: index->type & DICT_CLUSTERED
# 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.
----- 从这信息看是整理簇索引,导致表空间出现损坏
# /opt/mysql/product/5.1/bin/mysqld(_Z12mysql_deleteP3THDP10TABLE_LISTP4ItemP11st_sql_listyyb+0x86c)[0x66fc5c]
# /opt/mysql/product/5.1/bin/mysqld(_Z21mysql_execute_commandP3THD+0x38bf)[0x5f03af]
---分析的情况,你的系统应该正在做一个DELETE操作,而且应该无索引可走,删除的数据量也比较大
组合上述情况及个人经验:可能是大量数据被缓存在innodb_buffer_pool_size中,并且其内部有创建自适应的hash索引,因删除数据而不得不重新创建,以及你的服务器当时IO出现瓶颈,导致一时无法响应Innodb master thread,而出现问题....并且InnoDB引擎在此方面出现过BUG,解决版本是5.1.37之后,所以建议使用:5.1.40版本,较稳定....
回复

使用道具 举报

千问 | 2012-5-22 15:10:11 | 显示全部楼层
jinguanding 发表于 2011-11-28 22:53
mysqld got signal 6 --- 首先申明,对的错误号为6的多数问题,我还真没本事搞定,也是最复杂的....
# I ...

谢谢版主的分析
我看到出现故障前的binlog,最后显示的是delete操作,因为我的binlog_format设置的是row模式,所以我不能看到具体的sql
我请问下:设置了row模式,想看到具体sql,有办法吗?
回复

使用道具 举报

千问 | 2012-5-22 15:10:11 | 显示全部楼层
xifenfei 发表于 2011-11-28 22:59
谢谢版主的分析
我看到出现故障前的binlog,最后显示的是delete操作,因为我的binlog_format设置的是row ...

mysqlbinlog -v -v mysql-bin.000就可以了...
回复

使用道具 举报

千问 | 2012-5-22 15:10:11 | 显示全部楼层
建议设置为MIXED,因为设置为ROW模式,若是一次性删除大量数据的话,可能导致消耗大量物理IO,而使服务器性能急剧下降,二是MIXED模式也相对更靠谱....
回复

使用道具 举报

千问 | 2012-5-22 15:10:11 | 显示全部楼层
jinguanding 发表于 2011-11-28 23:07
mysqlbinlog -v -v mysql-bin.000就可以了...

好的,非常感谢,我现在就登陆服务器尝试下
回复

使用道具 举报

千问 | 2012-5-22 15:10:11 | 显示全部楼层
我整理到blog中
http://www.xifenfei.com/2007.html
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

主题

0

回帖

4882万

积分

论坛元老

Rank: 8Rank: 8

积分
48824836
热门排行