MySQL實例crash的案例詳細分析
【問題描述】
我們生產(chǎn)環(huán)境有一組集群的多臺MySQL服務(wù)器(MySQL 5.6.21),不定期的會crash,但error log中只記錄了重啟信息,未記錄crash時的堆棧:
mysqld_safe Number of processes running now: 0 mysqld_safe mysqld restarted
接下來首先排查系統(tǒng)日志/var/log/message文件,crash時沒有其他異常信息,也不是OOM導(dǎo)致的。
【排查思路】
由于日志中未記錄有價值的信息。為定位crash的原因,首先開啟mysql core dump的功能。
下面是開啟core dump的步驟:
1、 在my.cnf文件中增加2個配置項
[mysqld] core_file [mysqld_safe] core-file-size=unlimited
2、修改系統(tǒng)參數(shù),配置suid_dumpable
echo 1 >/proc/sys/fs/suid_dumpable
3、重啟mysql服務(wù),配置生效
【問題分析】
開啟core dump后,服務(wù)器再次crash時生成了core file。
用gdb分析生成的core file,可以看到crash時的堆棧信息如下:
從函數(shù)table_esms_by_digest::delete_all_rows
可以看出觸發(fā)crash的是truncate table events_statements_summary_by_digest操作。
我們內(nèi)部有個DML的分析工具,用來統(tǒng)計數(shù)據(jù)庫每分鐘增刪改查的訪問量。該工具的數(shù)據(jù)源是events_statements_summary_by_digest表,采集程序會每一分鐘采集一次這張表的數(shù)據(jù),采集完成后執(zhí)行truncate操作。
暫停這組集群上DML采集程序后MySQL沒有再發(fā)生crash。
進一步分析多個core file,發(fā)現(xiàn)最終函數(shù)的調(diào)用都發(fā)生在_lf_pinbox_real_free函數(shù)上。
結(jié)合現(xiàn)場環(huán)境,有兩處地方值得分析:
1、 內(nèi)存的不正常值。當打印該變量時,此處變量的地址偏低,不太正常:
(gdb) p pins->pinbox $2 = (LF_PINBOX *) 0x1367208
2、紅字部分為pfs逐條釋放digest記錄的操作,正在釋放某行數(shù)據(jù)時出現(xiàn)錯誤:
void reset_esms_by_digest() { uint index; if (statements_digest_stat_array == NULL) return; PFS_thread *thread= PFS_thread::get_current_thread(); if (unlikely(thread == NULL)) return; for (index= 0; index < digest_max; index++) { statements_digest_stat_array[index].reset_index(thread); statements_digest_stat_array[index].reset_data(); } digest_index= 1; }
猜測有兩種可能導(dǎo)致錯誤:
1、高并發(fā)下,對內(nèi)存訪問出現(xiàn)沖突;
2、某個特殊SQL導(dǎo)致,在處理hash時。
在網(wǎng)上搜索類似的問題,有了進一步的進展,基本確定了這個問題是bug導(dǎo)致
如下Mysql的bug report中講述了類似問題
https://bugs.mysql.com/bug.php?id=73979
更詳細的環(huán)境描述如下連接中
https://bugs.launchpad.net/percona-server/+bug/1351148
查到5.6.35上的bug fix的修復(fù)內(nèi)容,和我們碰到的情況非常類似。
對比_lf_pinbox_real_free的修改,該部分確實進行很大的調(diào)整。
下面是MySQL 5.6.35函數(shù)_lf_pinbox_real_free的代碼片段:
static void _lf_pinbox_real_free(LF_PINS pins) { LF_PINBOX pinbox= pins->pinbox; struct st_match_and_save_arg arg = {pins, pinbox, pins->purgatory}; pins->purgatory= NULL; pins->purgatory_count= 0; lf_dynarray_iterate(&pinbox->pinarray, (lf_dynarray_func)match_and_save, &arg); if (arg.old_purgatory) { void *last= arg.old_purgatory; while (pnext_node(pinbox, last)) last= pnext_node(pinbox, last); pinbox->free_func(arg.old_purgatory, last, pinbox->free_func_arg); } }
下面是MySQL 5.6.21函數(shù)的_lf_pinbox_real_free的代碼片段
static void _lf_pinbox_real_free(LF_PINS pins) { int npins; void list; void **addr= NULL; void first= NULL, last= NULL; LF_PINBOX pinbox= pins->pinbox; npins= pinbox->pins_in_array+1; if (pins->stack_ends_here != NULL) { int alloca_size= sizeof(void )LF_PINBOX_PINSnpins; if (available_stack_size(&pinbox, *pins->stack_ends_here) > alloca_size) { struct st_harvester hv; addr= (void **) alloca(alloca_size); hv.granary= addr; hv.npins= npins; _lf_dynarray_iterate(&pinbox->pinarray, (lf_dynarray_func)harvest_pins, &hv); npins= hv.granary-addr; if (npins) qsort(addr, npins, sizeof(void *), (qsort_cmp)ptr_cmp); } }
同時觀察到出問題的集群有指標異常,QPS不到6000,Threads_connected將近8000。(對比其他高并發(fā)的集群,QPS在20000以上,Threads_connected也只有300左右)。
排查應(yīng)用端的連接方式,了解到其中一個應(yīng)用有近百臺應(yīng)用服務(wù)器,可能同時發(fā)起請求,卻沒有合理的復(fù)用連接,維持大量的連接線程增大了bug觸發(fā)的概率。
Bugs Fixed的描述如下:
Miscalculation of memory requirements for qsort operations could result in stack overflow errors in situations with a large number of concurrent server connections. (Bug #73979, Bug #19678930, Bug #23224078)
【解決思路】
我們通過分析crash時的core file文件,找到crash時的觸發(fā)條件,暫停DML采集程序(truncate table events_statements_summary_by_digest操作)后恢復(fù)。
后面了解到這是MySQL的一個bug,在MySQL 5.6.35版本后已修復(fù)。這個bug在應(yīng)用端與數(shù)據(jù)庫建立大量的連接時,更容易觸發(fā)。
總結(jié)
以上就是這篇文章的全部內(nèi)容了,希望本文的內(nèi)容對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,如果有疑問大家可以留言交流,謝謝大家對腳本之家的支持。
相關(guān)文章
mysql5.7數(shù)據(jù)庫安裝完成后如何配置環(huán)境變量
這篇文章主要為大家詳細介紹了在win10系統(tǒng)下,mysql5.7數(shù)據(jù)庫安裝完成后配置環(huán)境變量的具體步驟,感興趣的小伙伴們可以參考一下2016-06-06SQL實現(xiàn)LeetCode(185.系里前三高薪水)
這篇文章主要介紹了SQL實現(xiàn)LeetCode(185.系里前三高薪水),本篇文章通過簡要的案例,講解了該項技術(shù)的了解與使用,以下就是詳細內(nèi)容,需要的朋友可以參考下2021-08-08MySQL同步數(shù)據(jù)Replication的實現(xiàn)步驟
本文主要介紹了MySQL同步數(shù)據(jù)Replication的實現(xiàn)步驟,文中通過示例代碼介紹的非常詳細,對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2023-03-03MySQL的子查詢及相關(guān)優(yōu)化學(xué)習(xí)教程
這篇文章主要介紹了MySQL的子查詢及相關(guān)優(yōu)化學(xué)習(xí)教程,使用子查詢時需要注意其對數(shù)據(jù)庫性能的影響,需要的朋友可以參考下2015-11-11mysql調(diào)優(yōu)的幾種方式小結(jié)
本文主要介紹了mysql調(diào)優(yōu)的幾種方式小結(jié),文中通過示例代碼介紹的非常詳細,對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2023-05-05mysql問題之slow log中出現(xiàn)大量的binlog dump記錄的解決方法
今天在查看mysql中發(fā)現(xiàn)比較慢,然后我使用了slow log,發(fā)現(xiàn)出現(xiàn)了大量的binlog dump記錄,下面我來給大家整理一下這個問題的解決辦法2013-09-09Mysql 5.7.19 免安裝版配置方法教程詳解(64位)
這篇文章主要介紹了Mysql 5.7.19 免安裝版配置方法教程詳解,需要的朋友可以參考下2017-08-08mysql8.0 用戶角色管理及授權(quán)的實現(xiàn)
MySQL是一種常見的關(guān)系型數(shù)據(jù)庫管理系統(tǒng),它提供了強大的安全機制來管理用戶權(quán)限,本文主要介紹了mysql8.0 用戶角色管理及授權(quán)的實現(xiàn),具有一定的參考價值,感興趣的可以了解一下2024-04-04Navicat for MySQL導(dǎo)出表結(jié)構(gòu)腳本的簡單方法
下面小編就為大家?guī)硪黄狽avicat for MySQL導(dǎo)出表結(jié)構(gòu)腳本的簡單方法。小編覺得挺不錯的,現(xiàn)在就分享給大家,也給大家做個參考。一起跟隨小編過來看看吧2016-12-12MySQL生產(chǎn)庫Insert了2次同樣的記錄但是主鍵ID是不一樣的問題的分析過程
這篇文章主要介紹了MySQL生產(chǎn)庫Insert了2次同樣的記錄但是主鍵ID是不一樣的問題的分析過程,需要的朋友可以參考下2014-02-02