MySQL實(shí)例crash的案例詳細(xì)分析
【問(wèn)題描述】
我們生產(chǎn)環(huán)境有一組集群的多臺(tái)MySQL服務(wù)器(MySQL 5.6.21)，不定期的會(huì)crash，但error log中只記錄了重啟信息，未記錄crash時(shí)的堆棧：
mysqld_safe Number of processes running now: 0 mysqld_safe mysqld restarted
接下來(lái)首先排查系統(tǒng)日志/var/log/message文件，crash時(shí)沒(méi)有其他異常信息，也不是OOM導(dǎo)致的。
【排查思路】
由于日志中未記錄有價(jià)值的信息。為定位crash的原因，首先開(kāi)啟mysql core dump的功能。
下面是開(kāi)啟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ù)，配置生效
【問(wèn)題分析】
開(kāi)啟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的分析工具，用來(lái)統(tǒng)計(jì)數(shù)據(jù)庫(kù)每分鐘增刪改查的訪問(wèn)量。該工具的數(shù)據(jù)源是events_statements_summary_by_digest表，采集程序會(huì)每一分鐘采集一次這張表的數(shù)據(jù)，采集完成后執(zhí)行truncate操作。
暫停這組集群上DML采集程序后MySQL沒(méi)有再發(fā)生crash。
進(jìn)一步分析多個(gè)core file，發(fā)現(xiàn)最終函數(shù)的調(diào)用都發(fā)生在_lf_pinbox_real_free函數(shù)上。
結(jié)合現(xiàn)場(chǎng)環(huán)境，有兩處地方值得分析：
1、 內(nèi)存的不正常值。當(dāng)打印該變量時(shí)，此處變量的地址偏低，不太正常：
(gdb) p pins->pinbox $2 = (LF_PINBOX *) 0x1367208
2、紅字部分為pfs逐條釋放digest記錄的操作，正在釋放某行數(shù)據(jù)時(shí)出現(xiàn)錯(cuò)誤：
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;
}
猜測(cè)有兩種可能導(dǎo)致錯(cuò)誤：
1、高并發(fā)下，對(duì)內(nèi)存訪問(wèn)出現(xiàn)沖突；
2、某個(gè)特殊SQL導(dǎo)致，在處理hash時(shí)。
在網(wǎng)上搜索類似的問(wèn)題，有了進(jìn)一步的進(jìn)展，基本確定了這個(gè)問(wèn)題是bug導(dǎo)致
如下Mysql的bug report中講述了類似問(wèn)題
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)容，和我們碰到的情況非常類似。
對(duì)比_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í)觀察到出問(wèn)題的集群有指標(biāo)異常，QPS不到6000，Threads_connected將近8000。（對(duì)比其他高并發(fā)的集群，QPS在20000以上，Threads_connected也只有300左右）。
排查應(yīng)用端的連接方式，了解到其中一個(gè)應(yīng)用有近百臺(tái)應(yīng)用服務(wù)器，可能同時(shí)發(fā)起請(qǐng)求，卻沒(méi)有合理的復(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)
【解決思路】
我們通過(guò)分析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ù)庫(kù)建立大量的連接時(shí)，更容易觸發(fā)。
總結(jié)
以上就是這篇文章的全部?jī)?nèi)容了，希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，如果有疑問(wèn)大家可以留言交流，謝謝大家對(duì)腳本之家的支持。
相關(guān)文章
MySQL特定表全量、增量數(shù)據(jù)同步到消息隊(duì)列-解決方案
mysql要同步原始全量數(shù)據(jù)，也要實(shí)時(shí)同步MySQL特定庫(kù)的特定表增量數(shù)據(jù)，同時(shí)對(duì)應(yīng)的修改、刪除也要對(duì)應(yīng),下面就為大家分享一下2021-11-11
MySQL 快速刪除大量數(shù)據(jù)（千萬(wàn)級(jí)別）的幾種實(shí)踐方案詳解
這篇文章主要介紹了MySQL 快速刪除大量數(shù)據(jù)（千萬(wàn)級(jí)別）的幾種實(shí)踐方案詳解，文中通過(guò)示例代碼介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面隨著小編來(lái)一起學(xué)習(xí)學(xué)習(xí)吧2020-07-07
MySQL系列之開(kāi)篇 MySQL關(guān)系型數(shù)據(jù)庫(kù)基礎(chǔ)概念
數(shù)據(jù)庫(kù)是指長(zhǎng)期儲(chǔ)存在計(jì)算機(jī)中的有組織的、可共享的數(shù)據(jù)集合，數(shù)據(jù)具有三大基本特點(diǎn)，永久存儲(chǔ)，有組織，可共享，是數(shù)據(jù)庫(kù)系統(tǒng)的核心，本文給大家分享MySQL關(guān)系型數(shù)據(jù)庫(kù)基礎(chǔ)概念，需要的朋友參考下吧2021-07-07
CentOS mysql安裝還是很常用的軟件，我就學(xué)習(xí)如何CentOS mysql安裝，在這里拿出來(lái)和大家分享一下，希望對(duì)大家有用。2010-11-11
關(guān)于數(shù)據(jù)庫(kù)中的查詢優(yōu)化
這篇文章主要介紹了關(guān)于數(shù)據(jù)庫(kù)中的查詢優(yōu)化,對(duì)于大型的應(yīng)用系統(tǒng)，數(shù)據(jù)動(dòng)輒上百萬(wàn)，就需要了解DBMS對(duì)查詢語(yǔ)句的處理過(guò)程和優(yōu)化算法，更好的利用其優(yōu)化算法，以提高系統(tǒng)的性能,需要的朋友可以參考下2023-07-07
本文主要介紹了MySQL持久化和回滾的原理，文中通過(guò)示例代碼介紹的非常詳細(xì)，具有一定的參考價(jià)值，感興趣的小伙伴們可以參考一下2021-11-11
這篇文章主要介紹了MySQL的查詢緩存和Buffer Pool，幫助大家更好的理解和學(xué)習(xí)MySQL 數(shù)據(jù)庫(kù)，感興趣的朋友可以了解下2020-11-11
MySQL存儲(chǔ)引擎的實(shí)現(xiàn)要素分析
這篇文章主要為大家介紹了MySQL存儲(chǔ)引擎的實(shí)現(xiàn)要素分析,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2023-09-09
MySQL配置文件my.cnf中文版，使用mysql的朋友可以參考下，了解每個(gè)參數(shù)的重要性。2011-09-09
這篇文章主要給大家分享的是MySQL語(yǔ)句匯總整理，圍繞MySQL語(yǔ)句的相關(guān)資料對(duì)其進(jìn)行整理，具有一定的參考價(jià)值，需要的小伙伴可以參考一下，希望對(duì)你有所幫助2021-12-12