問題定位：
進入容器內，查詢mysql的日誌，沒有發現異常問題(有些錯誤日誌資訊，應該是容器自定義的時候留下的)，所以排除問題是在容器內發生的。
回到宿主機，查詢容器日誌，路徑/var/lib/docker/containers發現有一句異常：
資料庫未正常關閉!？僅僅一條這樣的報錯還是定位不到問題的，遂查了docker的日誌，也沒有發現有價值的資訊，想到linux的程序都是由linux的核心在進行排程和管理的，遂查了kernel的日誌(路徑/var/log/messages)，發現有兩條值得關注的資訊：
有乙個容器程序被kill了！通過查了oom_kill，得到如下資訊：
oomkiller，即out of memory killer,是linux下面當記憶體耗盡時的的一種處理機制。當記憶體較少時，oom會遍歷整個程序鍊錶，然後根據程序的記憶體使用情況以及它的oom score值最終找到得分較高的程序，然後傳送kill訊號將其殺掉。
結合我們的配置和查詢得到的訊息，初步猜想問題出現在記憶體不足上，將資料庫容器啟動，並使用命令docker stats檢視容器的資源使用，驗證我們的猜想：這次容器的異常宕機是因為宿主機的記憶體不足引起的。
解決方法：啟用swap增加伺服器的可用記憶體
1.在根目錄下建立swap檔案，因為這台伺服器的配置為2g，交換分割槽大小一般為物理記憶體大小的200%，所以我們建立乙個大小為4gb的預分配空間的檔案。
#建立檔案
fallocate -l 4g /swap
#檢查ls -lh /swap
2.啟用該檔案
#為了確保安全性，修改檔案許可權
chmod 600 /swap
#應用檔案於swap
#記錄下該環節輸出的uuid，我這裡的uuid為：21197dd4-78c5-46a0-828b-ee14bbc7be83
mkswap /swap
#開始使用swap分割槽
swapon /swap
#驗證一
swapon -s
#驗證二
free
3.修改掛載檔案使之永久生效
#在/etc/fstab中新增一行
#前面的數值為uuid
配置完成後，容器的宕機概率應該會下降的，如果還是同樣的錯誤，那只能加錢解決了。
done!
Mysql日誌 慢查詢日誌
3.設定variables的示範 慢查詢日誌能為sql語句的優化帶來很好的幫助。可以設定乙個閾值，將執行時間超過該值的所有sql語句都記錄到慢查詢日誌檔案中。閾值long query time表示慢查詢的時間閾值，預設值為10，代表10秒。注 慢查詢日誌只會記錄大於閾值的sql語句，小於和等於的sq...
mysql查詢日誌分析 mysql日誌分析
日誌檔案 log 就是乙個跟蹤記錄的列表，它可以協助我們時刻掌握系統及應用服務的動作狀態，在故障排查的時候提供最詳細準確地資訊，幫助我們快速查詢原因，減少我們憑主觀的經驗去猜測，這樣的答案更具有說服力，機器通常是不會撒謊的。任何的系統，無論是作業系統 資料庫 應用伺服器他們都會有自己的log檔案，而...
mysql的查詢日誌 mysql
這篇文章總結了mysql中查詢日誌的知識點。mysql中，日誌可以按照功能分為如下幾類。錯誤日誌 查詢日誌 慢查詢日誌 二進位制日誌 中繼日誌 innodb儲存引擎級別的事務日誌 查詢日誌 查詢日誌在mysql中被稱之為general log 通用日誌 不要被 查詢日誌 的名字誤導，錯誤的以為查詢日...