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後，問題沒有再現。
獲取更多更及時的文章資訊，請關注我的微信公眾號
