mysql core文件的正確打開姿式

     最近兩天本身負責的一個實例頻繁出現crash的狀況，分析了日誌，大體明白了crash的緣由，可是沒有定位到具體的SQL，也沒有找到很好的規避的辦法，所以想在mysql出現crash的時候自動將內存堆棧相關的信息保存到core文件，而後經過gdb分析再結合源碼來肯定致使mysql crash的根本緣由。

     由於以前在linux下操做過core文件的設置，所以想固然地經過ulimit -c unlimited打開linux的core文件設置，而後喝茶，靜靜等待core文件的產生。終於等到實例出現crash，可是core文件並無如期產生。查了下mysql的官方文檔，發現還須要經過 --core-file啓動或者將core_file配置到配置文件，而後重啓實例。以下圖的官方文檔所示：

此次涉及到實例重啓，多少會影響業務，爲了謹慎期間，特意找了個測試環境，按照以下配置進行操做：

一、打開linux的core文件配置

    ulimit -c unlimited

二、添加mysql的core_file配置（備註：配置在[mysqld]下面），並重啓測試實例

三、模擬mysql的crash場景，執行以下命令

    kill -SEGV  `pidof mysqld`

操做完成後並未如期出現core文件，經過google發現有人遇到了和我同樣的困惑，發現還有幾個地方須要設置了，繼續測試，此次按照以下步驟進行操做:

一、打開linux的core文件配置

    ulimit -c unlimited

二、添加mysql的core_file配置（備註：配置在[mysqld]下面），並重啓測試實例

三、配置 suid_dumpable（ mysql 一般會以 suid 方式啓動 ）

    echo 2 >/proc/sys/fs/suid_dumpable

四、設置core文件存放的目錄而且設置徹底控制權限

    mkdir /data/core && chmod 777 /data/core && echo "/data/core/core" > /proc/sys/kernel/core_pattern

五、模擬mysql的crash場景，執行以下命令

    kill -SEGV  `pidof mysqld`

kill操做執行完成後，終於看到了久違的core文件。總結mysql的core文件正確打開方式以下：

一、打開linux的core文件配置

    ulimit -c unlimited

二、添加mysql的core_file配置（備註：配置在[mysqld]下面），並重啓測試實例

三、配置 suid_dumpable（ mysql 一般會以 suid 方式啓動 ）

    echo 2 >/proc/sys/fs/suid_dumpable

四、設置core文件存放的目錄而且設置徹底控制權限

    mkdir /data/core && chmod 777 /data/core && echo "/data/core/core" > /proc/sys/kernel/core_pattern

注意：打開core配置後會有以下兩個風險

一、磁盤空間可能會滿

    ----由於會將mysql server的全部內存信息導出到core文件中，包括buffer pool中的內容，可能會有幾十上百G大小

二、mysql出現crash後啓動速度會慢

    ----由於要導出大量的數據到core文件中，所以啓動速度會慢不少。 參考資料： https://dev.mysql.com/doc/refman/5.5/en/server-options.html#option_mysqld_core-file https://www.percona.com/blog/2011/08/26/getting-mysql-core-file-on-linux/