共计 3362 个字符,预计需要花费 9 分钟才能阅读完成。
这篇文章主要介绍 MySQL 实例 crash 的示例分析,文中介绍的非常详细,具有一定的参考价值,感兴趣的小伙伴们一定要看完!
【问题描述】
我们生产环境有一组集群的多台 MySQL 服务器 (MySQL 5.6.21),不定期的会 crash,但 error log 中只记录了重启信息,未记录 crash 时的堆栈:
mysqld_safe Number of processes running now: 0
mysqld_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;
}
猜测有两种可能导致错误:
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 的代码片段:
static void _lf_pinbox_real_free(LF_PINS pins)
LF_PINBOX pinbox= pins- pinbox;
struct st_match_and_save_arg arg = {pins, pinbox, pins- purgatory};
pins- purgatory= NULL;
pins- purgatory_count= 0;
lf_dynarray_iterate( pinbox- pinarray,
(lf_dynarray_func)match_and_save, arg);
if (arg.old_purgatory)
void *last= arg.old_purgatory;
while (pnext_node(pinbox, last))
last= pnext_node(pinbox, last);
pinbox- free_func(arg.old_purgatory, last, pinbox- free_func_arg);
}
下面是 MySQL 5.6.21 函数的_lf_pinbox_real_free 的代码片段
static void _lf_pinbox_real_free(LF_PINS pins)
int npins;
void list;
void **addr= NULL;
void first= NULL, last= NULL;
LF_PINBOX pinbox= pins- pinbox;
npins= pinbox- pins_in_array+1;
if (pins- stack_ends_here != NULL)
int alloca_size= sizeof(void )LF_PINBOX_PINSnpins;
if (available_stack_size( pinbox, *pins- stack_ends_here) alloca_size)
struct st_harvester hv;
addr= (void **) alloca(alloca_size);
hv.granary= addr;
hv.npins= npins;
_lf_dynarray_iterate( pinbox- pinarray,
(lf_dynarray_func)harvest_pins, hv);
npins= hv.granary-addr;
if (npins)
qsort(addr, npins, sizeof(void *), (qsort_cmp)ptr_cmp);
}
同时观察到出问题的集群有指标异常,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 的示例分析”这篇文章的所有内容,感谢各位的阅读!希望分享的内容对大家有帮助,更多相关知识,欢迎关注丸趣 TV 行业资讯频道!