MySQL 5.6.21集群crash原因探究：truncatetableevents_statements_summary_b...

本文档详细探讨了一组MySQL 5.6.21集群在生产环境中遇到的不定期crash问题。问题的关键在于，尽管error log只记录了重启过程，而没有堆栈信息。为了解决这一问题，作者采取了开启mysql core dump功能的方法来定位崩溃原因。 【问题描述】 集群中的MySQL服务器经常遭遇crash，但错误日志缺乏crash时的具体堆栈信息，仅显示"mysqld_safe: Number of processes running now: 0" 和 "mysqld_safe: mysqld restarted"。初步排查并未在/var/log/message中找到异常或oom相关的线索。 【排查思路与方法】 为获取崩溃时的更多信息，作者决定启用core dump功能，具体步骤包括： 1. 在my.cnf文件中添加配置项，如"[mysqld] core_file" 和 "[mysqld_safe] core-file-size=unlimited"，以允许在crash时保存核心转储文件。 2. 修改系统参数，设置suid_dumpable为1，确保权限正确。 3. 重启mysql服务，使得配置生效。 【问题分析与发现】 启用core dump后，当服务器再次crash时，生成了corefile。通过gdb分析，发现崩溃源于table_esms_by_digest::delete_all_rows函数，由于内部的DML分析工具频繁执行truncatetableevents_statements_summary_by_digest操作，从而触发了crash。当暂停DML采集程序时，MySQL运行稳定，表明问题可能与该工具的数据采集相关。 深入分析多个corefile后，crash点集中在_lf_pinbox_real_free函数。特别值得注意的是： 1. 内存中的一个变量地址偏低，这可能是内存管理问题的一个线索，暗示可能存在内存泄漏或其他内存异常。 2. 在pfs的digest记录释放过程中，出现了错误，这可能与数据结构处理或内存操作的并发控制有关。 【后续步骤与结论】 对于这个案例，建议进行更深入的内存检查，包括使用内存分析工具（如Valgrind）来确认内存泄漏或异常。同时，研究_pinbox_real_free函数的实现，找出为何会在释放数据时出错，可能是某个条件判断失误或者竞态条件。修复这些问题后，才能从根本上解决MySQL实例的crash问题，提高系统的稳定性和可靠性。