問題
我的 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 的技術內容，你們還有什麼想知道的嗎？趕緊留言告訴小編吧！
