![e4b8e8adb9c31e75c7337309e3efc0c1.png](https://img-blog.csdnimg.cn/img_convert/e4b8e8adb9c31e75c7337309e3efc0c1.png)
问题
我的 MySQL 偶尔崩溃,如果需要追查原因,应该如何保留现场?
实验
MySQL 随着版本不停迭代,崩溃的现象越来越少,也越来越隐蔽。
一旦遇到生产环境上的 MySQL 崩溃,就需要保留现场信息,供分析用。虽然 MySQL 的 error log 中会打印部分信息,但对于比较隐蔽的崩溃,往往显得力不从心。
因此我推荐开启 coredump,以备 MySQL 诊断需要。
我们来模拟一个崩溃场景,然后配置 coredump 看看效果。
选取一个容易复现崩溃的 bug,我们选择了 bug #95294。
![ad2207868917c98b661db55ba977651a.png](https://img-blog.csdnimg.cn/img_convert/ad2207868917c98b661db55ba977651a.png)
我们先安装一个 5.7 的数据库,
![e45280759f53d8808e441e952353abd2.png](https://img-blog.csdnimg.cn/img_convert/e45280759f53d8808e441e952353abd2.png)
将其停掉,按照 bug #95294 的描述变更配置,
![ea61a7e22af94ab3f39d68a6c3004d9a.png](https://img-blog.csdnimg.cn/img_convert/ea61a7e22af94ab3f39d68a6c3004d9a.png)
手工启动 mysqld,可以看到 mysqld 无声无息的退出了,
![41df5ac188a72fb4d24ea68b2532bf8e.png](https://img-blog.csdnimg.cn/img_convert/41df5ac188a72fb4d24ea68b2532bf8e.png)
检查 error log,可以看到 MySQL 是因为异常崩溃了,
![f34af28e9a70c74e506b86651e84f145.png](https://img-blog.csdnimg.cn/img_convert/f34af28e9a70c74e506b86651e84f145.png)
error log 中有一段堆栈信息,可以用来判断这个崩溃的问题,
![8414c74a89e3b821b43a9712419969f8.png](https://img-blog.csdnimg.cn/img_convert/8414c74a89e3b821b43a9712419969f8.png)
以上是 MySQL 能提供的所有信息,无法针对一些复杂场景进行分析。
下面我们开启 coredump,让 MySQL 在崩溃时能提供更多信息:
以下命令开启了系统级别一些参数,具体的释义大家可自行谷歌。此处需要注意,我们将 core 文件生成到了 /tmp 目录下,需要保证其磁盘空间足够大:
![0014c2191247cc7c2082789dc97a0f7b.png](https://img-blog.csdnimg.cn/img_convert/0014c2191247cc7c2082789dc97a0f7b.png)
我们还需要调整 MySQL 运行用户的 ulimit,在本文中,MySQL 的运行用户是 root,我们调整其 core file 的限制,使其能生成 core dump:
![ea74ec44270ec2922d635651f1e1e4f8.png](https://img-blog.csdnimg.cn/img_convert/ea74ec44270ec2922d635651f1e1e4f8.png)
最后,我们要在 MySQL 配置里,允许 MySQL 生成 coredump:
![938bc5cca5de2b97aeec7b835c2fe403.png](https://img-blog.csdnimg.cn/img_convert/938bc5cca5de2b97aeec7b835c2fe403.png)
现在我们可以再次运行 MySQL:
![f34579d16e9d93dd9123a73f60437b1b.png](https://img-blog.csdnimg.cn/img_convert/f34579d16e9d93dd9123a73f60437b1b.png)
可以看到 MySQL 崩溃时,会告知已生成了 core dump 文件。在 error log 中也会有同样的信息:
![2d64aa3f2ac70ba48ad788e42ff3ad4b.png](https://img-blog.csdnimg.cn/img_convert/2d64aa3f2ac70ba48ad788e42ff3ad4b.png)
我们来看一下这个 coredump 文件:
![922c3e306e9a57f022dbd785fbb94aef.png](https://img-blog.csdnimg.cn/img_convert/922c3e306e9a57f022dbd785fbb94aef.png)
coredump 文件会将崩溃当时的内存情况全部保留下来,所以文件体积会比较大。
小贴士:
在 MySQL 8.0.14 后,MySQL 提供了参数 innodb_buffer_pool_in_core_file,用于将 innodb buffer pool 从 coredump 中排除,用于减小 coredump 的体积。
那我们怎么使用 coredump 文件呢?可以用 gdb 去访问 coredump 文件,获取各种信息,此处举例如何获取所有线程的堆栈信息。
![b2f499d46b212f2c679b2b0049e2dfcd.png](https://img-blog.csdnimg.cn/img_convert/b2f499d46b212f2c679b2b0049e2dfcd.png)
我们会得到一个非常长的堆栈信息,我们截取其中一小段,标注上简单的中文即可看懂。
![9e14764dfffb9404a85ab69b7d7ced42.png](https://img-blog.csdnimg.cn/img_convert/9e14764dfffb9404a85ab69b7d7ced42.png)
结论
通过开启操作系统级别、放开用户限制、启用 MySQL 参数三个步骤,我们启用了 MySQL 的 coredump 功能,使得 MySQL 崩溃时留下了足够的线索。
对于复杂崩溃的分析,还是需要将 coredump 交给专业的研发工程师手里,或者提交给 MySQL 开发团队。
不过不管是什么场景,能提供一份 coredump,所有技术人员都会感谢你的。
关于 MySQL 的技术内容,你们还有什么想知道的吗?赶紧留言告诉小编吧!
![1f07e243766548a541805958f28260fd.png](https://img-blog.csdnimg.cn/img_convert/1f07e243766548a541805958f28260fd.png)