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后，问题没有再现。

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