MySQL数据库crash的问题分析

 【问题】

生产环境有多台slave服务器,不定期的会crash,下面是error log中的堆栈信息

Thread pointer: 0x7f1e54b26410

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 = 7f1ed98e6e28 thread_stack 0x40000

/usr/sbin/mysqld(my_print_stacktrace+0x35)[0xf438c5]

/usr/sbin/mysqld(handle_fatal_signal+0x4a4)[0x7ce014]

/lib64/libpthread.so.0[0x3ef280f7e0]

/usr/sbin/mysqld[0x132713a]

/usr/sbin/mysqld(_Z23well_formed_copy_ncharsPK15charset_info_stPcmS1_PKcmmPS4_S5_S5_+0xba)[0xde2c2a]

/usr/sbin/mysqld(_Z29field_well_formed_copy_ncharsPK15charset_info_stPcmS1_PKcmmPS4_S5_S5_+0x66)[0x7f4e06]

/usr/sbin/mysqld(_ZN10Field_blob14store_internalEPKcmPK15charset_info_st+0x1dc)[0x80037c]

/usr/sbin/mysqld(_ZN17Fill_process_listclEP3THD+0x4c9)[0xd6b089]

/usr/sbin/mysqld(_ZN18Global_THD_manager19do_for_all_thd_copyEP11Do_THD_Impl+0x26d)[0x7cca9d]

/usr/sbin/mysqld(_Z23fill_schema_processlistP3THDP10TABLE_LISTP4Item+0x43)[0xd54143]

/usr/sbin/mysqld[0xd52d57]

/usr/sbin/mysqld(_Z24get_schema_tables_resultP4JOIN23enum_schema_table_state+0x1cc)[0xd52fec]

/usr/sbin/mysqld(_ZN4JOIN14prepare_resultEv+0x6d)[0xd485cd]

/usr/sbin/mysqld(_ZN4JOIN4execEv+0xc0)[0xcde670]

/usr/sbin/mysqld(_Z12handle_queryP3THDP3LEXP12Query_resultyy+0x250)[0xd49370]

/usr/sbin/mysqld(_ZN21Sql_cmd_insert_select7executeEP3THD+0x3bc)[0xe944ac]

/usr/sbin/mysqld(_Z21mysql_execute_commandP3THDb+0xfc0)[0xd0b0a0]

/usr/sbin/mysqld(_Z11mysql_parseP3THDP12Parser_state+0x3a5)[0xd0f605]

/usr/sbin/mysqld(_Z16dispatch_commandP3THDPK8COM_DATA19enum_server_command+0x17a8)[0xd10e18]

/usr/sbin/mysqld(_Z10do_commandP3THD+0x194)[0xd11764]

/usr/sbin/mysqld(handle_connection+0x2bc)[0xde4d0c]

/usr/sbin/mysqld(pfs_spawn_thread+0x174)[0x1255534]

/lib64/libpthread.so.0[0x3ef2807aa1]

/lib64/libc.so.6(clone+0x6d)[0x3ef20e8bcd]

 

【分析过程】

从生成2个core file分析来看,有一些发现:

1、 报错发生在查询information_schema.processlist表的INFO字段

 

2、 值拷贝函数well_formed_copy_nchars,传入参数from_length的长度是65535,说明当时正在执行超长的SQL语句,INFO字段被截断了

第1个core.184694文件

发生异常的代码行,在验证字符串的2个字节时报错

 

第2个core.61979文件

发生异常的代码行,在获取字符串的第一个字节时报错

 

3、从字符集来看,from_cs是UTF8,to_cs也是UTF8,值拷贝时字符集从UTF8到UTF8

 

【结论】

目前可以确定的触发条件是DB在执行长度大于65535的SQL语句,同时执行information_schema.processlist的查询语句。

发生的两台服务器都是slave,可以推测可能是主库执行了包含二进制或大文本字段的insert、update、delete语句,在ROW模式下所有执行的语句记录到日志时,记录了每一行数据每个字段的修改。

这样比起master更容易出现超长的SQL语句,同时也提高了问题发生的概率。

将主从复制模式从ROW改为MIXED后,问题没有再现。

 

获取更多更及时的文章信息,请关注我的微信公众号

posted @ 2018-12-06 18:26  wangdong  阅读(1127)  评论(0编辑  收藏