最近兩天自己負責的乙個例項頻繁出現crash的情況，分析了日誌，大致明白了crash的原因，但是沒有定位到具體的sql，也沒有找到很好的規避的辦法，因此想在mysql出現crash的時候自動將記憶體堆疊相關的資訊儲存到core檔案，然後通過gdb分析再結合原始碼來確定導致mysql crash的根本原因。
因為之前在linux下操作過core檔案的設定，因此想當然地通過ulimit -c unlimited開啟linux的core檔案設定，然後喝茶，靜靜等待core檔案的產生。終於等到例項出現crash，但是core檔案並沒有如期產生。查了下mysql的官方文件，發現還需要通過
--core-file啟動或者將core_file配置到配置檔案，然後重啟例項。如下圖的官方文件所示：
這次涉及到例項重啟，多少會影響業務，為了謹慎期間，特地找了個測試環境，按照如下配置進行操作：
1、開啟linux的core檔案配置
ulimit -c unlimited
2、新增mysql的core_file配置（備註：配置在[mysqld]下面），並重啟測試例項
3、模擬mysql的crash場景，執行如下命令
kill -se** `pidof mysqld`
操作完成後並未如期出現core檔案，通過google發現有人遇到了和我一樣的困惑，發現還有幾個地方需要設定了，繼續測試，這次按照如下步驟進行操作:
1、開啟linux的core檔案配置
ulimit -c unlimited
2、新增mysql的core_file配置（備註：配置在[mysqld]下面），並重啟測試例項
3、配置
suid_dumpable（
mysql 通常會以 suid 方式啟動）
echo 2 >/proc/sys/fs/suid_dumpable
4、設定core檔案存放的目錄並且設定完全控制許可權
mkdir /data/core && chmod 777 /data/core && echo "/data/core/core" > /proc/sys/kernel/core_pattern
5、模擬mysql的crash場景，執行如下命令
kill -se** `pidof mysqld`
kill操作執行完成後，終於看到了久違的core檔案。總結mysql的core檔案正確開啟方式如下：
1、開啟linux的core檔案配置
ulimit -c unlimited
2、新增mysql的core_file配置（備註：配置在[mysqld]下面），並重啟測試例項
3、配置
suid_dumpable（
mysql 通常會以 suid 方式啟動）
echo 2 >/proc/sys/fs/suid_dumpable
4、設定core檔案存放的目錄並且設定完全控制許可權
mkdir /data/core && chmod 777 /data/core && echo "/data/core/core" > /proc/sys/kernel/core_pattern
注意：開啟core配置後會有如下兩個風險
1、磁碟空間可能會滿
----因為會將mysql server的所有記憶體資訊匯出到core檔案中，包括buffer pool中的內容，可能會有幾十上百g大小
2、mysql出現crash後啟動速度會慢
----因為要匯出大量的資料到core檔案中，因此啟動速度會慢很多。
判斷List集合為空還是null的正確開啟方式
最近在寫乙個專案的時候遇到乙個這樣乙個問題，我簡單的還原一下場景，這是模擬乙個簡單的管理系統 一張簡單的客戶表 create table customer id int 11 not null auto increment unique,name varchar 255 not null,gende...
如何正確讀寫檔案
看題 請指出下面 段中的錯誤 f open test.txt mode w f.write u python之禪 分析 python 提供了內建函式 open 用於讀寫檔案，函式返回乙個檔案物件，可對檔案進行讀 寫操作，用引數 mode 來控制。引數 說明 r 讀檔案 預設 w 寫檔案 如果檔案中有...
正確上傳檔案技巧
使用者的角度上說，上傳正確的檔案應是自律為主。上傳檔案應該遵守兩個原則，首先就是確定這個檔案一定會使用到才會上傳，其次就是是盡量的小。下面，我舉例說明一下。比如使用者上傳，jpg gif 和 png 格式所能展現的效果和內容是不同的，但不建議採用上述格式以外的其他格式作為上傳檔案。這裡，有乙個連線詳...