MySQL啟動不了（MySQL一開啟就閃退）

問題

我的 MySQL 偶爾崩潰，如果需要追查原因，應該如何保留現場？

實驗

MySQL 隨著版本不停迭代，崩潰的現象越來越少，也越來越隱蔽。

一旦遇到生產環境上的 MySQL 崩潰，就需要保留現場資訊，供分析用。雖然 MySQL 的 error log 中會列印部分資訊，但對於比較隱蔽的崩潰，往往顯得力不從心。

因此我推薦開啟 coredump，以備 MySQL 診斷需要。

我們來模擬一個崩潰場景，然後配置 coredump 看看效果。

選取一個容易復現崩潰的 bug，我們選擇了 bug #95294。

我們先安裝一個 5.7 的資料庫，

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

手工啟動 mysqld，可以看到 mysqld 無聲無息的退出了，

檢查 error log，可以看到 MySQL 是因為異常崩潰了，

error log 中有一段堆疊資訊，可以用來判斷這個崩潰的問題，

以上是 MySQL 能提供的所有資訊，無法針對一些複雜場景進行分析。

下面我們開啟 coredump，讓 MySQL 在崩潰時能提供更多資訊：

以下命令開啟了系統級別一些引數，具體的釋義大家可自行谷歌。此處需要注意，我們將 core 檔案生成到了 /tmp 目錄下，需要保證其磁碟空間足夠大：

我們還需要調整 MySQL 執行使用者的 ulimit，在本文中，MySQL 的執行使用者是 root，我們調整其 core file 的限制，使其能生成 core dump：

最後，我們要在 MySQL 配置裡，允許 MySQL 生成 coredump：

現在我們可以再次執行 MySQL：

可以看到 MySQL 崩潰時，會告知已生成了 core dump 檔案。在 error log 中也會有同樣的資訊：

我們來看一下這個 coredump 檔案：

coredump 檔案會將崩潰當時的記憶體情況全部保留下來，所以檔案體積會比較大。

小貼士：

在 MySQL 8.0.14 後，MySQL 提供了引數
   innodb_buffer_pool_in_core_file，用於將 innodb buffer pool 從 coredump 中排除，用於減小 coredump 的體積。

那我們怎麼使用 coredump 檔案呢？可以用 gdb 去訪問 coredump 檔案，獲取各種資訊，此處舉例如何獲取所有執行緒的堆疊資訊。

我們會得到一個非常長的堆疊資訊，我們擷取其中一小段，標註上簡單的中文即可看懂。

結論

通過開啟作業系統級別、放開使用者限制、啟用 MySQL 引數三個步驟，我們啟用了 MySQL 的 coredump 功能，使得 MySQL 崩潰時留下了足夠的線索。

對於複雜崩潰的分析，還是需要將 coredump 交給專業的研發工程師手裡，或者提交給 MySQL 開發團隊。

不過不管是什麼場景，能提供一份 coredump，所有技術人員都會感謝你的。

關於 MySQL 的技術內容，你們還有什麼想知道的嗎？趕緊留言告訴小編吧！