共計 3362 個字符，預(yù)計需要花費 9 分鐘才能閱讀完成。
這篇文章主要介紹 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=unlimited2、修改系統(tǒng)參數(shù)，配置 suid_dumpable
echo 1 /proc/sys/fs/suid_dumpable3、重啟 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 *) 0x13672082、紅字部分為 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ā)。
以上是“MySQL 實例 crash 的示例分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！希望分享的內(nèi)容對大家有幫助，更多相關(guān)知識，歡迎關(guān)注丸趣 TV 行業(yè)資訊頻道！
