mysql crash定位分析_MySQL实例crash的案例详细分析

文章详细介绍了在MySQL 5.6.21环境中,集群不定期crash的问题。通过对系统日志、开启core dump、分析core file,发现crash源于对events_statements_summary_by_digest表的truncate操作,以及潜在的内存冲突或特定SQL导致的错误。排查发现是MySQL的bug,已在5.6.35版本修复。解决方案是暂停触发问题的DML采集程序,并考虑升级到修复bug的版本。
摘要由CSDN通过智能技术生成

【问题描述】

我们生产环境有一组集群的多台MySQL服务器(MySQL 5.6.21),不定期的会crash,但error log中只记录了重启信息,未记录crash时的堆栈:

mysqld_safe Number of processes running now: 0mysqld_safe mysqld restarted

接下来首先排查系统日志/var/log/message文件,crash时没有其他异常信息,也不是OOM导致的。

【排查思路】

由于日志中未记录有价值的信息。为定位crash的原因,首先开启mysql core dump的功能。

下面是开启core dump的步骤:

1、 在my.cnf文件中增加2个配置项

[mysqld]core_file[mysqld_safe]core-file-size=unlimited

2、修改系统参数,配置suid_dumpable

echo 1 >/proc/sys/fs/suid_dumpable

3、重启mysql服务,配置生效

【问题分析】

开启core dump后,服务器再次crash时生成了core file。

用gdb分析生成的core file,可以看到crash时的堆栈信息如下:

f4c0946cc3d6c0b424280632a64c8b27.png

从函数table_esms_by_digest::delete_all_rows可

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值