mysql has gone away
自從上次出現(xiàn)了mysql has gone away 錯誤以后 ，有朋友回答是鏈接超時原因 引起的。 gateway 模型里 常駐內(nèi)存運行的 連接 能否做一個機制 在底層 建立起的連接 每一定時間 向mysql服務(wù) 請求一次 以保持 連接不被斷開呢？ 我了解到 gateway 目前的方式 還是太被 動了，是等到請求時 發(fā)現(xiàn)已經(jīng)報錯 再連接一次 。這么做的話 后面的再連接一次 也不是太穩(wěn)固。 我現(xiàn)在的gateway里 就還是出現(xiàn)了 gone away。
3個回答
打賞
出現(xiàn)mysql gone away Gateway的 DbConnection會自動重連的，但是仍然會有一個warning，你可以重新更新下gateway框架，新版本屏蔽了這個waring。
定時ping并不能解決根本問題，連接還是有被斷開的可能，最靠譜的就是目前的判斷錯誤碼重連的方案。
還有 其實定時ping 和 出錯時重連不沖突 可以雙管齊下 ，定時ping 間隔時間長 對資源消耗 可以忽略不計啊。 另外 ，到出錯時的重連 排除硬性因素（比如mysql 服務(wù)宕機等） 在連接已經(jīng)失效的情況下 重連 成功率高嗎？ 會不會再次連接不成功。這種情況怎么處理呢？ 畢竟服務(wù)不容出差錯啊。 關(guān)鍵時刻 取不到數(shù)據(jù) 這是致命的。
- 暫無評論
雙管齊下有點多余了，如果開發(fā)者想要定時ping，加個定時器就好，非常簡單。
在連接已經(jīng)失效的情況下 重連 成功率高嗎？
msyql關(guān)閉鏈接的時間一般是8小時，8小時只重連一次，效率問題完全可以忽略。另外8小時都沒請求，這個業(yè)務(wù)也并不是繁忙業(yè)務(wù)，也不用考慮這點消耗。
會不會再次連接不成功。這種情況怎么處理呢？畢竟服務(wù)不容出差錯啊。 關(guān)鍵時刻 取不到數(shù)據(jù) 這是致命的。
出現(xiàn)mysql gone away 后DbConnection只會重連一次，如果失敗，就拋異常。業(yè)務(wù)可以捕獲這個異常，然后根據(jù)數(shù)據(jù)重要情況自行決定如何處理。如果沒捕獲異常進程會退出重啟一次。
- 暫無評論
