這篇文章主要介紹MySQL實(shí)例crash的示例分析，文中介紹的非常詳細(xì)，具有一定的參考價(jià)值，感興趣的小伙伴們一定要看完！

十余年專注成都網(wǎng)站制作，成都企業(yè)網(wǎng)站定制，個(gè)人網(wǎng)站制作服務(wù)，為大家分享網(wǎng)站制作知識、方案，網(wǎng)站設(shè)計(jì)流程、步驟,成功服務(wù)上千家企業(yè)。為您提供網(wǎng)站建設(shè),網(wǎng)站制作,網(wǎng)頁設(shè)計(jì)及定制高端網(wǎng)站建設(shè)服務(wù),專注于成都企業(yè)網(wǎng)站定制,高端網(wǎng)頁制作,對三輪攪拌車等多個(gè)方面，擁有多年的網(wǎng)站設(shè)計(jì)經(jīng)驗(yàn)。

【問題描述】

我們生產(chǎn)環(huán)境有一組集群的多臺MySQL服務(wù)器(MySQL 5.6.21)，不定期的會crash，但error log中只記錄了重啟信息，未記錄crash時(shí)的堆棧：

mysqld_safe Number of processes running now: 0
mysqld_safe mysqld restarted

接下來首先排查系統(tǒng)日志/var/log/message文件，crash時(shí)沒有其他異常信息，也不是OOM導(dǎo)致的。

【排查思路】

由于日志中未記錄有價(jià)值的信息。為定位crash的原因，首先開啟mysql core dump的功能。

下面是開啟core dump的步驟：

1、 在my.cnf文件中增加2個(gè)配置項(xiàng)

[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時(shí)生成了core file。

用gdb分析生成的core file，可以看到crash時(shí)的堆棧信息如下：

從函數(shù)table_esms_by_digest::delete_all_rows可以看出觸發(fā)crash的是truncate table events_statements_summary_by_digest操作。

我們內(nèi)部有個(gè)DML的分析工具，用來統(tǒng)計(jì)數(shù)據(jù)庫每分鐘增刪改查的訪問量。該工具的數(shù)據(jù)源是events_statements_summary_by_digest表，采集程序會每一分鐘采集一次這張表的數(shù)據(jù)，采集完成后執(zhí)行truncate操作。

暫停這組集群上DML采集程序后MySQL沒有再發(fā)生crash。

進(jìn)一步分析多個(gè)core file，發(fā)現(xiàn)最終函數(shù)的調(diào)用都發(fā)生在_lf_pinbox_real_free函數(shù)上。

結(jié)合現(xiàn)場環(huán)境，有兩處地方值得分析：

1、 內(nèi)存的不正常值。當(dāng)打印該變量時(shí)，此處變量的地址偏低，不太正常：

(gdb) p pins->pinbox

$2 = (LF_PINBOX *) 0x1367208

2、紅字部分為pfs逐條釋放digest記錄的操作，正在釋放某行數(shù)據(jù)時(shí)出現(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、某個(gè)特殊SQL導(dǎo)致，在處理hash時(shí)。

在網(wǎng)上搜索類似的問題，有了進(jìn)一步的進(jìn)展，基本確定了這個(gè)問題是bug導(dǎo)致

如下Mysql的bug report中講述了類似問題

https://bugs.mysql.com/bug.php?id=73979

更詳細(xì)的環(huán)境描述如下連接中

https://bugs.launchpad.net/percona-server/+bug/1351148

查到5.6.35上的bug fix的修復(fù)內(nèi)容，和我們碰到的情況非常類似。

對比_lf_pinbox_real_free的修改，該部分確實(shí)進(jìn)行很大的調(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);

}

}

同時(shí)觀察到出問題的集群有指標(biāo)異常，QPS不到6000，Threads_connected將近8000。（對比其他高并發(fā)的集群，QPS在20000以上，Threads_connected也只有300左右）。

排查應(yīng)用端的連接方式，了解到其中一個(gè)應(yīng)用有近百臺應(yīng)用服務(wù)器，可能同時(shí)發(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時(shí)的core file文件，找到crash時(shí)的觸發(fā)條件，暫停DML采集程序（truncate table events_statements_summary_by_digest操作）后恢復(fù)。

后面了解到這是MySQL的一個(gè)bug，在MySQL 5.6.35版本后已修復(fù)。這個(gè)bug在應(yīng)用端與數(shù)據(jù)庫建立大量的連接時(shí)，更容易觸發(fā)。

以上是“MySQL實(shí)例crash的示例分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！希望分享的內(nèi)容對大家有幫助，更多相關(guān)知識，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道！