MySQL Bug导致异常宕机的分析流程

本文主要通过一个bug来记录一下如何分析一个MySQL bug的崩溃信息。
版本:Percona 5.7.17-11

这部分是数据库崩溃的时候的栈帧，因为收到的是信号6 SIGABRT，只要捕获信号后改变其行为即可。这部分在MySQL官方文档中叫做Stack Trace，参考：

实际上在这里我们已经可以看到大约是统计数据收集的问题，因为我们看到了dict_stats_thread，这是统计收集线程的回调函数。

获取如下：

如：vi /tmp/err0222.log放入即可

如：nm -D -n ./mysqld > /tmp/mysqld.sym

如下：

实际上到这里通过函数的调用我们可以发现是统计数据收集出现了问题。

在报错信息中提起比较代表性的信息在官方网站中进行搜索通过在percona中查看发现本bug由上游MySQL代码造成BUG号：Bug #84940
并且发现在5.7.18中得到修复同时给出了内部BUG号如下：

这里请教了阿里的印风兄才知道怎么查看，首先拿到了内部bug号：24585978
然后在git的commit log中搜索得到
git –no-pager log >/root/commitlog
vi /root/commitlog 找到commit号为：
29acdaaaeef9afe32b42785f1da3d79d56ed7e59
如下是这个bug的修复地方：

这里是我的浅显的分析，不对的地方的还请见谅。
我们发现这里实际上修改就是多了一个括号而已，但是意义是相当重要的。

修改前：
如果level != 0 不管innodb_stats_include_delete_marked参数如何设置必然触发判断是否存在del_flag,然后通过设置偏移量的方式 跳过这行，但是随后的(*total_recs)++; 将不会触发，极端情况下可能为0。
而在上层代码dict_stats_analyze_index中的found_level:地方实际上是开发云主机域名需要非叶子结点行数不为0的如下：

在官网查看的时候有如下方式可以规避这个Bug

设置这些参数后实际上是使用的老的非固化的统计数据收集的方式，而不会通过线程dict_stats_thread收集下面是逻辑片段位于row_update_statistics_if_needed中如下：

这样做的话肯定不会调用到触发bug的函数，有兴趣的可以看看dict_stats_update(table, DICT_STATS_RECALC_TRANSIENT);的逻辑。实际上使用的是老的方式断点可以打在btr_estimate_number_of_different_key_vals函数上。

作者微信：

相关推荐: Java工作流系统-父子流程的配置讲解

关键字： 驰骋工作流程快速开发平台 工作流程管理系统 工作流引擎 asp.net工作流引擎 java工作流引擎. 开发者表单 拖拽式表单 工作流系统 适配数据库： oralce,mysql,sqlserver,Informix, PostgreSQL 达梦 应…