mysql server has gone away的緣由

 以前遇到開發詢問「mysql server has gone away」的問題，想固然的就認爲是因爲太長時間沒有操做，致使超過MySQL服務端上的wait_timeout的設置，最終鏈接被MySQL服務端回收了。

最近一次忽然本身同事寫的腳本在運行過程當中被中斷了，查看報錯信息依然是「mysql server has gone away」，同事的腳本在多個MySQL實例上根據時間範圍取值，雖然執行時間長了點，可是絕對不會有超過wati_timeout的空閒等待時間，因而去學習了一下到底有哪幾種狀況會出現這個報錯。

狀況1

就是最多見的，一個連接超過wait_timeout的設置時間沒有作任何事情，被MySQL服務端關閉連接並回收資源。 
針對這種狀況要不調大wait_timeout或者不斷的向MySQL服務端發送心跳信號，保持連接。

狀況2

你的連接被kill掉了，有多是DBA人工操做，也多是各類自動化系統操做，能夠經過監控status中com_kill狀態值來判斷剛纔是否發生了kill操做。

狀況3

MySQL的客戶端若是默認配置中有mysql_opt_read_timeout或者mysql_opt_write_timeout參數，而且操做時間超過了其中一個參數的設置，客戶端自身會關閉連接。因此須要瞭解本身使用的mysql客戶端。

狀況4

還有一種多是發送的請求或者返回的結果集太大了，超過MySQL的max_allowed_packet_size的設置，致使發生這種報錯。多說一句，這個參數須要客戶端和服務端同時配置並保持一致纔會生效。 
最多見的Linux上的mysql客戶端可使用以下命令查看：

mysql --help | grep ^max-allowmax-allowed-packet 1677721

咱們能夠看到咱們服務器上默認的設置爲16M。

狀況5

這種比較罕見的狀況是MySQL服務端的DNS反解失敗致使，理論上咱們能夠配置–skip-networking參數來規避這種問題。（可是官方文檔竟然說即便配置了也可能出現這種報錯，T_T）

狀況6

還有就是若是程序使用了多進程，而全部進程都嘗試使用同一個連接和MySQL服務端創建連接的時候就會出現gone away的報錯了。（初步懷疑，這也就是我同事遇到的問題了。）

狀況7

最後這種比較弱，可是真實發生過，那就是mysql實例宕機了。實例都沒有了，天然什麼都沒有了。固然這種狀況判斷起來比較方便，通常都會有mysql的存活監控。可是要當心一種狀況，就是實例crash後迅速recover，若是監控程序的間隔大於recover的時間，那麼就很難發現了。建議使用以下方法複查一下，另外針對uptime最好作爲狀態的一個必要監控點。

show global status like 'uptime';+---------------+---------+| Variable_name | Value   |+---------------+---------+| Uptime        | 1230699 |+---------------+---------+

 

最後若是想對「mysql server has gone away」進行詳細的追查，建議在mysqld實例啓動的時候添加–log-warnings=2 參數，這樣就能夠在error日誌中看到詳細的信息了。