最近两天自己负责的一个实例频繁出现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/
参考资料：
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/