MySQL实例crash深度剖析：truncatetableevents_statements_summary_by_diges...

本文将深入探讨MySQL实例crash的案例，针对生产环境中多台MySQL 5.6.21服务器出现的不定期crash问题进行详细分析。问题发生时，错误日志中缺乏崩溃堆栈信息，仅记录了重启过程。为了定位问题，作者采取了一系列排查步骤： 1. **开启mysql core dump功能**：首先在my.cnf文件中添加了`core_file`配置项，并设置了`core-file-size=unlimited`，允许在服务崩溃时生成corefile。同时，调整系统参数`suid_dumpable`，使得corefile可以正确生成。 2. **收集崩溃核心文件**：在开启了core dump之后，当服务器再次crash，corefile成功生成，这为后续的故障诊断提供了关键线索。 3. **利用gdb分析堆栈信息**：通过gdb工具解析corefile，发现崩溃是由`table_esms_by_digest::delete_all_rows`中的`truncatetableevents_statements_summary_by_digest`操作引起的。这与数据库内一个用于监控DML（数据修改）活动的分析工具紧密相关，该工具每分钟从`events_statements_summary_by_digest`表获取数据并执行truncate操作。 4. **停止DML采集程序的影响**：通过暂停这个采集程序，服务器的crash现象得以缓解，表明这个问题可能与该工具的频繁操作有关。 5. **深入核心函数的分析**：进一步分析多个corefile显示，崩溃点集中在`_lf_pinbox_real_free`函数上。这提示可能存在内存管理问题，特别是当查看到某个变量地址偏低时，可能预示着内存泄漏或其他内存异常。 6. **现场环境的两点关注**： - **内存异常**：变量地址的不正常可能是内存溢出或内存管理不当的迹象。 - **潜在的并发问题**：由于涉及到多台服务器和频繁的DML操作，可能存在并发控制或锁竞争的问题，导致内存泄露或资源争抢引发crash。 通过对crash核心文件的深入分析，文章提供了一种逐步排查和定位MySQL实例crash问题的方法，包括检查内存异常、分析高频率操作对系统的影响以及可能的并发问题。这对于MySQL管理员和开发人员来说，是一个实用的学习案例，可以帮助他们更好地理解和解决类似问题。