
MySQL报障之coredump收集处理流程
1.配置coredump
core文件是在程序出现异常退出时,保留的异常堆栈文件,能够帮助开发人员快速定位问题,故对于线上的程序,需要开启coredump功能。可以通过配置core-file或者coredumper开启coredump功能。
1.1core-file
我们需要在my.cnf中的[mysqld]里面加上如下配置。
默认情况下,生成的core文件会出现在对应的datadir目录。
启动mysqld_safe之前,操作系统也需要做一些配置:
1.2coredumper
如果没有root权限,无法进行操作系统全局更改时,可以使用如下配置进行配置。
启动mysqld_safe之前,操作系统也需要做一些配置:
这样只会影响mysql用户。
core文件会产生在datadir目录。
2.现场初步分析
2.1分析error log
首先需要在error log中,搜索backtrace关键字查找异常堆栈。
可以从这里看到如下几个信息:
1.Query (7f913ef65028): select * from grid-report.dp_bi_main_order_acccum limit 0, 1000语句导致的堆栈异常
2.最后core在了build_order_list_string函数,且函数内的偏移是0x6c
3.Server Version: 8.0.25-15-mysqlcluster5.0.7-GA MySQL Cluster, Release GA, Revision b43d2b2e462, 这里是commit版本号,我们需要使用发布对应这个版本号的二进制。
2.2调试core文件
此信息需要截图。可以联系研发协助打印一些变量信息。
3.信息搜集
经过上面的初步分析,需要搜集如下文件提交给研发人员进一步分析。
1.error log
2.general log
3.core文件,如果研发之前已经搜集到了,可以不用传出来。
4.导致core的query涉及到的表的建表语句以及数据(数据需要看研发是否需要)。
如果general log很大,需要DBA截取core之前1小时或者10万行的日志即可,可以通过grep、head、tail等命令截取相关日志。
1.通过error日志确定core的时间点
2.通过grep在general log中定位到具体时间点的行号 x
3.通过head -n x general.log | tail -n 100000 > general.log.coredump
4.参考文档
• MySQL is crashing: a support engineer’s point of view(https://www.percona.com/blog/2015/08/17/mysql-is-crashing-a-support-engineers-point-of-view/)
• Say Hello to Libcoredumper(https://www.percona.com/blog/2020/10/28/say-hello-to-libcoredumper-a-new-way-to-generate-core-dumps-and-other-improvements/)
