我理解了一些mysql的默認變量配置,這些默認配置在高壓力的生產環境中被證明是有問題的,這些默認配置在網絡震盪或一些其他情況下會產生一些讓人非常討厭的問題。
max_connect_errors
如果客戶端連接mysql的時候有錯誤發生,服務器將會放棄等待在(connect_timeout)秒之后,並且會增加錯誤連接主機的計數。然后直到這個值達到(max_connect_errors)https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_max_connect_errors,然后客戶端的ip會被鎖定禁止連接,直到你執行 FLUSH HOST命令。更糟糕的情況是,如果你的網絡不穩定，並且你一直不重啟mysql服務器，這個錯誤會隨着時間積累 直至在某個深夜給你造成無限麻煩。
閱讀Mysql官網的文章(Host 'host name' is blocked)https://dev.mysql.com/doc/refman/5.7/en/blocked-host.html。不幸的是他們沒有辦法全完徹底的避免這種情況。這是這個值為0也不能避免這種情況。比較現實的解決方案是設置一個比較大的值 (max_connect_errors=1844674407370954751),並且時不時的運行一下FLUSH HOSTS命令。
connect_timeout
這個值和上面的問題相關.在網絡擁堵的情況下(包含客戶端和服務器),有可能在幾秒鍾之后完成連接。但是這個參數的默認值是5秒,當你嘗試忽略這個錯誤,上面的max_connect_errors 會給你造成麻煩。
為了避免這種情況,可以嘗試設置connect_timeout的值在15到20 之間。也可以考慮設置thread_cache_size為一個非零值。如果服務器需要在很短的時間內新建大量連接,這樣的配置會非常有幫助.
skip-name-resolve
默認情況下對進入服務器的連接mysql會進行反向查找.在這種情況下,不管你的基礎服務有多好,對DNS服務總是會有干擾.mysql 的主機緩存是為了將這些查找降到最低.但是這種情況困擾了我8年了.當有錯誤發生的時候,我只能假設在主機緩存或者解析器之中存在bug.
我推薦在/etc/my.cnf增加skip-name-resolve完全跳過DNS查找。只使用ip地址或者被允許的ip段.這樣從DNS得到應答將會十分緩慢,非常容易的達到connect_timeout值。我猜測有2到3個DNS服務配置,但是第一個DNS服務是不可用的.
slave_net_timeout
當主數據庫和從數據庫之間的網絡連接出現故障,但是主從都沒有檢測到(比如防火牆或者路由的改變)。你一定希望從服務器在slave_net_timeout秒之后可以自己明白發生了某些錯誤.他會嘗試再次連接主服務器,在丟失連接的地方重新上線.這樣就太了不起。
然而,這個值很令人沮喪 3600秒 整整一個小時.
如果發生某些錯誤,難道會有人希望他的從服務器空轉嗎?我不認為有人希望這種情況發生.
我的建議是你,如果你在一個非常混亂的環境,你可以設置這個值為30秒。
文章翻譯自mysql