MySQL实例crash的示例分析

这篇文章主要介绍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?id=73979
更详细的环境描述如下连接中
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的描述如下：
Miscalculation of memory requirements for qsort operations could result in stack overflow errors in situations with a large number of concurrent server connections. (Bug #73979, Bug #19678930, Bug #23224078)
【解决思路】
我们通过分析crash时的core file文件，找到crash时的触发条件，暂停DML采集程序（truncate table events_statements_summary_by_digest操作）后恢复。
后面了解到这是MySQL的一个bug，在MySQL 5.6.35版本后已修复。这个bug在应用端与数据库建立大量的连接时，更容易触发。以上是“MySQL实例crash的示例分析”这篇文章的所有内容，感谢各位的阅读！希望分享的内容对大家有帮助，更多相关知识，欢迎关注开发云行业资讯频道！

相关推荐: 一次差异备份拿shell过程

扫描器扫到了某个网站存在目录浏览，于是便有了本文。。。知识点科普：目录浏览在我个人看来是危害较大的一个漏洞，该漏洞是指“在没有默认文档的目录下，列出该目录下所有文件名及文件信息”，如果站点存在这种错误配置，***者如果知道其中目录名，则可以查看到这些目录下的文…