问题
我的 MySQL 偶尔崩溃,如果需要追查原因,应该如何保留现场?
实验
MySQL 随着版本不停迭代,崩溃的现象越来越少,也越来越隐蔽。
一旦遇到生产环境上的 MySQL 崩溃,就需要保留现场信息,供分析用。虽然 MySQL 的 error log 中会打印部分信息,但对于比较隐蔽的崩溃,往往显得力不从心。
因此我推荐开启 coredump,以备 MySQL 诊断需要。
我们来模拟一个崩溃场景,然后配置 coredump 看看效果。
选取一个容易复现崩溃的 bug,我们选择了 bug #95294。
![84a86e7cdaf74644ad35a771ae03170a.png](https://i-blog.csdnimg.cn/blog_migrate/daf0eba125e7b01cdb3df8245b1a0ecb.jpeg)
我们先安装一个 5.7 的数据库,
![af00e95c73ab64280828217d0c313aa3.png](https://i-blog.csdnimg.cn/blog_migrate/c35806fc89dfca1ca1fdcdcb3db0a5c7.jpeg)
将其停掉,按照 bug #95294 的描述变更配置,
![d8f8fdab337f4a07e3ab8965b5d7f393.png](https://i-blog.csdnimg.cn/blog_migrate/cda2fb7d62aee4b2d6bcee98519dad10.jpeg)
手工启动 mysqld,可以看到 mysqld 无声无息的退出了,
![2b0314b8b979aaacfd9adbc38dd816b9.png](https://i-blog.csdnimg.cn/blog_migrate/e6c152f2361404045ecfd804ab98b554.jpeg)
检查 error log,可以看到 MySQL 是因为异常崩溃了,
![6ace4c2cd46236979ecbd1b03b7b1b4e.png](https://i-blog.csdnimg.cn/blog_migrate/ba5b0e5adaeb506aebbf53ef2116791d.jpeg)
error log 中有一段堆栈信息,可以用来判断这个崩溃的问题,
![553b3bb09c904800c81d394f3b2b4cf5.png](https://i-blog.csdnimg.cn/blog_migrate/2591ba9e55e828f72fdf63bf07a14078.jpeg)
以上是 MySQL 能提供的所有信息,无法针对一些复杂场景进行分析。
下面我们开启 coredump,让 MySQL 在崩溃时能提供更多信息:
以下命令开启了系统级别一些参数,具体的释义大家可自行谷歌。此处需要注意,我们将 core 文件生成到了 /tmp 目录下,需要保证其磁盘空间足够大:
![55cdfe5a29ec14e82c72945f2edaf3c5.png](https://i-blog.csdnimg.cn/blog_migrate/9631588fd850ba5da305ab7ca7775d9d.jpeg)
我们还需要调整 MySQL 运行用户的 ulimit,在本文中,MySQL 的运行用户是 root,我们调整其 core file 的限制,使其能生成 core dump:
![4d1661fc404639b2edad8d8e6a79389a.png](https://i-blog.csdnimg.cn/blog_migrate/9729eafea409746ec74b0194384768fb.jpeg)
最后,我们要在 MySQL 配置里,允许 MySQL 生成 coredump:
![d4fae090a8554c64adfa699f436fcb4a.png](https://i-blog.csdnimg.cn/blog_migrate/c3c74e6157d66936713c7c0cb2075747.jpeg)
现在我们可以再次运行 MySQL:
![611fc940f2f4b1d3b9ca367e82c2481b.png](https://i-blog.csdnimg.cn/blog_migrate/1db9951fb1d7d31c6cedf1ff1bd89e44.jpeg)
可以看到 MySQL 崩溃时,会告知已生成了 core dump 文件。在 error log 中也会有同样的信息:
![a235854574255b26ce0ccbc4529da58b.png](https://i-blog.csdnimg.cn/blog_migrate/94338af3f6d41ae1d3d04be3e8362ea0.jpeg)
我们来看一下这个 coredump 文件:
![14d5e4b4c5286c7489b71ffa6d008814.png](https://i-blog.csdnimg.cn/blog_migrate/9850a73f9624c1627eed327a7ee6b722.jpeg)
coredump 文件会将崩溃当时的内存情况全部保留下来,所以文件体积会比较大。
在 MySQL 8.0.14 后,MySQL 提供了参数 innodb_buffer_pool_in_core_file,用于将 innodb buffer pool 从 coredump 中排除,用于减小 coredump 的体积。
那我们怎么使用 coredump 文件呢?可以用 gdb 去访问 coredump 文件,获取各种信息,此处举例如何获取所有线程的堆栈信息。
![ca9a964eb2dd5e9dcdc181669ee4528f.png](https://i-blog.csdnimg.cn/blog_migrate/8d8cb7a690f5b46346a04e03de0f03d0.jpeg)
我们会得到一个非常长的堆栈信息,我们截取其中一小段,标注上简单的中文即可看懂。
![b39b096a2a66926bf51745b0ea39086a.png](https://i-blog.csdnimg.cn/blog_migrate/fbaff0a96a268b7235a197a5aa443661.jpeg)
结论
通过开启操作系统级别、放开用户限制、启用 MySQL 参数三个步骤,我们启用了 MySQL 的 coredump 功能,使得 MySQL 崩溃时留下了足够的线索。
对于复杂崩溃的分析,还是需要将 coredump 交给专业的研发工程师手里,或者提交给 MySQL 开发团队。
不过不管是什么场景,能提供一份 coredump,所有技术人员都会感谢你的。
关于爱可生
爱可生成立于2003年,依托于融合、开放、创新的数据处理技术和服务能力,为大型行业用户的特定场景提供深度挖掘数据价值的解决方案。
公司持续积累的核心关键技术,覆盖到分布式数据库集群、云数据平台、数据库大体量运管平台、海量数据集成于存储、清洗与治理、人工智能分析挖掘、可视化展现、安全与隐私保护等多个领域。
公司已与多个行业内的专业公司建立了长期伙伴关系,不断促进新技术与行业知识相结合,为用户寻求新的数据驱动的价值增长点。公司已在金融、能源电力、广电、政府等行业取得了众多大型用户典型成功案例,获得了市场的认可和业务的持续增长。
![dea12ddc93d0482be707446befecaedb.png](https://i-blog.csdnimg.cn/blog_migrate/acf7c734b2921ddbd781a5d0209c38ee.jpeg)