【問題描述】
我們生產環境有一組集群的多臺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;} |
