最近两天自己负责的一个实例频繁出现crash的情况，分析了日志，大致明白了crash的原因，但是没有定位到具体的SQL，也没有找到很好的规避的办法，因此想在mysql出现crash的时候自动将内存堆栈相关的信息保存到core文件，然后通过gdb分析再结合源码来确定导致mysql crash的根本原因。

因为之前在linux下操作过core文件的设置，因此想当然地通过ulimit -c unlimited打开linux的core文件设置，然后喝茶，静静等待core文件的产生。终于等到实例出现crash，但是core文件并没有如期产生。查了下mysql的官方文档，发现还需要通过 --core-file启动或者将core_file配置到配置文件，然后重启实例。如下图的官方文档所示：

这次涉及到实例重启，多少会影响业务，为了谨慎期间，特地找了个测试环境，按照如下配置进行操作：

1、打开linux的core文件配置

ulimit -c unlimited

2、添加mysql的core_file配置(备注：配置在[mysqld]下面)，并重启测试实例

3、模拟mysql的crash场景，执行如下命令

kill -SEGV  `pidof mysqld`

操作完成后并未如期出现core文件，通过google发现有人遇到了和我一样的困惑，发现还有几个地方需要设置了，继续测试，这次按照如下步骤进行操作:

1、打开linux的core文件配置

ulimit -c unlimited

2、添加mysql的core_file配置(备注：配置在[mysqld]下面)，并重启测试实例

3、配置 suid_dumpable( mysql 通常会以 suid 方式启动)

echo 2 >/proc/sys/fs/suid_dumpable

4、设置core文件存放的目录并且设置完全控制权限

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

5、模拟mysql的crash场景，执行如下命令

kill -SEGV  `pidof mysqld`

kill操作执行完成后，终于看到了久违的core文件。总结mysql的core文件正确打开方式如下：

1、打开linux的core文件配置

ulimit -c unlimited

2、添加mysql的core_file配置(备注：配置在[mysqld]下面)，并重启测试实例

3、配置 suid_dumpable( mysql 通常会以 suid 方式启动)

echo 2 >/proc/sys/fs/suid_dumpable

4、设置core文件存放的目录并且设置完全控制权限

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

注意：打开core配置后会有如下两个风险

1、磁盘空间可能会满

----因为会将mysql server的所有内存信息导出到core文件中，包括buffer pool中的内容，可能会有几十上百G大小

2、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/