设为首页 加入收藏

TOP

MySQL实例crash的案例分析
2018-12-27 14:14:40 】 浏览:34
Tags:MySQL 实例 crash 案例分析

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


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


由于日志中未记录有价值的信息。为定位crash的原因,首先开启mysql core dump的功能。
下面是开启core dump的步骤:
1、 在my.cnf文件中增加2个配置项


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


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


开启core dump后,服务器再次crash时生成了core file。
用gdb分析生成的core file,可以看到crash时的堆栈信息如下:


从函数table_esms_by_digest::delete_all_rows可以看出触发crash的是truncate table events_statements_summary_by_digest操作。
我们内部有个DML的分析工具,用来统计数据库每分钟增删改查的访问量。该工具的数据源是events_statements_summary_by_digest表,采集程序会每一分钟采集一次这张表的数据,采集完成后执行truncate操作。
暂停这组集群上DML采集程序后MySQL没有再发生crash。


进一步分析多个core file,发现最终函数的调用都发生在_lf_pinbox_real_free函数上。
结合现场环境,有两处地方值得分析:


1、 内存的不正常值。当打印该变量时,此处变量的地址偏低,不太正常:


2、红字部分为pfs逐条释放digest记录的操作,正在释放某行数据时出现错误:


猜测有两种可能导致错误:
1、高并发下,对内存访问出现冲突;
2、某个特殊SQL导致,在处理hash时。


在网上搜索类似的问题,有了进一步的进展,基本确定了这个问题是bug导致


如下Mysql的bug report中讲述了类似问题
https://bugs.mysql.com/bug.php?>
更详细的环境描述如下连接中
https://bugs.launchpad.net/percona-server/+bug/1351148


查到5.6.35上的bug fix的修复内容,和我们碰到的情况非常类似。
对比_lf_pinbox_real_free的修改,该部分确实进行很大的调整。


下面是MySQL 5.6.35函数_lf_pinbox_real_free的代码片段:



下面是MySQL 5.6.21函数的_lf_pinbox_real_free的代码片段



同时观察到出问题的集群有指标异常,QPS不到6000,Threads_connected将近8000。(对比其他高并发的集群,QPS在20000以上,Threads_connected也只有300左右)。


排查应用端的连接方式,了解到其中一个应用有近百台应用服务器,可能同时发起请求,却没有合理的复用连接,维持大量的连接线程增大了bug触发的概率。


Bugs Fixed的描述如下:


我们通过分析crash时的core file文件,找到crash时的触发条件,暂停DML采集程序(truncate table events_statements_summary_by_digest操作)后恢复。
后面了解到这是MySQL的一个bug,在MySQL 5.6.35版本后已修复。这个bug在应用端与数据库建立大量的连接时,更容易触发。



编程开发网
】【打印繁体】【投稿】【收藏】 【推荐】【举报】【评论】 【关闭】 【返回顶部
上一篇MySQL中min和max查询优化 下一篇关于MySQL连接抛出Authentication..

评论

帐  号: 密码: (新用户注册)
验 证 码:
表  情:
内  容:

array(4) { ["type"]=> int(8) ["message"]=> string(24) "Undefined variable: jobs" ["file"]=> string(32) "/mnt/wp/cppentry/do/bencandy.php" ["line"]=> int(214) }