【问题描述】
我们生产环境有一组集群的多台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时的堆栈信息如下：
从函数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、 内存的不正常值。当打印该变量时，此处变量的地址偏低，不太正常：
| (gdb) p pins->pinbox$2 = (LF_PINBOX *) 0x1367208 |
2、红字部分为pfs逐条释放digest记录的操作，正在释放某行数据时出现错误：
| void reset_esms_by_digest(){uint index;if (statements_digest_stat_array == NULL)return;PFS_thread *thread= PFS_thread::get_current_thread();if (unlikely(thread == NULL))return;for (index= 0; index < digest_max; index++){statements_digest_stat_array[index].reset_index(thread);statements_digest_stat_array[index].reset_data();}digest_index= 1;} |
