問(wèn)題

我的 MySQL 偶爾崩潰，如果需要追查原因，應(yīng)該如何保留現(xiàn)場(chǎng)？

實(shí)驗(yàn)

MySQL 隨著版本不停迭代，崩潰的現(xiàn)象越來(lái)越少，也越來(lái)越隱蔽。

一旦遇到生產(chǎn)環(huán)境上的 MySQL 崩潰，就需要保留現(xiàn)場(chǎng)信息，供分析用。雖然 MySQL 的 error log 中會(huì)打印部分信息，但對(duì)于比較隱蔽的崩潰，往往顯得力不從心。

因此我推薦開(kāi)啟 coredump，以備 MySQL 診斷需要。

我們來(lái)模擬一個(gè)崩潰場(chǎng)景，然后配置 coredump 看看效果。

選取一個(gè)容易復(fù)現(xiàn)崩潰的 bug，我們選擇了 bug #95294。

我們先安裝一個(gè) 5.7 的數(shù)據(jù)庫(kù)，

將其停掉，按照 bug #95294 的描述變更配置，

手工啟動(dòng) mysqld，可以看到 mysqld 無(wú)聲無(wú)息的退出了，

檢查 error log，可以看到 MySQL 是因?yàn)楫惓１罎⒘?#xff0c;

error log 中有一段堆棧信息，可以用來(lái)判斷這個(gè)崩潰的問(wèn)題，

以上是 MySQL 能提供的所有信息，無(wú)法針對(duì)一些復(fù)雜場(chǎng)景進(jìn)行分析。

下面我們開(kāi)啟 coredump，讓 MySQL 在崩潰時(shí)能提供更多信息：

以下命令開(kāi)啟了系統(tǒng)級(jí)別一些參數(shù)，具體的釋義大家可自行谷歌。此處需要注意，我們將 core 文件生成到了 /tmp 目錄下，需要保證其磁盤空間足夠大：

我們還需要調(diào)整 MySQL 運(yùn)行用戶的 ulimit，在本文中，MySQL 的運(yùn)行用戶是 root，我們調(diào)整其 core file 的限制，使其能生成 core dump：

最后，我們要在 MySQL 配置里，允許 MySQL 生成 coredump：

現(xiàn)在我們可以再次運(yùn)行 MySQL：

可以看到 MySQL 崩潰時(shí)，會(huì)告知已生成了 core dump 文件。在 error log 中也會(huì)有同樣的信息：

我們來(lái)看一下這個(gè) coredump 文件：

coredump 文件會(huì)將崩潰當(dāng)時(shí)的內(nèi)存情況全部保留下來(lái)，所以文件體積會(huì)比較大。

在 MySQL 8.0.14 后，MySQL 提供了參數(shù) innodb_buffer_pool_in_core_file，用于將 innodb buffer pool 從 coredump 中排除，用于減小 coredump 的體積。

那我們?cè)趺词褂?coredump 文件呢？可以用 gdb 去訪問(wèn) coredump 文件，獲取各種信息，此處舉例如何獲取所有線程的堆棧信息。

我們會(huì)得到一個(gè)非常長(zhǎng)的堆棧信息，我們截取其中一小段，標(biāo)注上簡(jiǎn)單的中文即可看懂。

結(jié)論

通過(guò)開(kāi)啟操作系統(tǒng)級(jí)別、放開(kāi)用戶限制、啟用 MySQL 參數(shù)三個(gè)步驟，我們啟用了 MySQL 的 coredump 功能，使得 MySQL 崩潰時(shí)留下了足夠的線索。

對(duì)于復(fù)雜崩潰的分析，還是需要將 coredump 交給專業(yè)的研發(fā)工程師手里，或者提交給 MySQL 開(kāi)發(fā)團(tuán)隊(duì)。

不過(guò)不管是什么場(chǎng)景，能提供一份 coredump，所有技術(shù)人員都會(huì)感謝你的。

關(guān)于 MySQL 的技術(shù)內(nèi)容，你們還有什么想知道的嗎？趕緊留言告訴小編吧！

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎(jiǎng)勵(lì)來(lái)咯，堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎(jiǎng)

總結(jié)

以上是生活随笔為你收集整理的系统崩溃mysql怎么保存表_第09问：MySQL 莫名崩溃，如何保留现场？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。