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/