這期內(nèi)容當(dāng)中小編將會(huì)給大家?guī)?lái)有關(guān)MySQL 以及JAVA 連接錯(cuò)誤的示例分析，文章內(nèi)容豐富且以專(zhuān)業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

成都創(chuàng)新互聯(lián)公司專(zhuān)注于光澤企業(yè)網(wǎng)站建設(shè),自適應(yīng)網(wǎng)站建設(shè),商城網(wǎng)站建設(shè)。光澤網(wǎng)站建設(shè)公司,為光澤等地區(qū)提供建站服務(wù)。全流程按需定制開(kāi)發(fā)，專(zhuān)業(yè)設(shè)計(jì)，全程項(xiàng)目跟蹤，成都創(chuàng)新互聯(lián)公司專(zhuān)業(yè)和態(tài)度為您提供的服務(wù)

最近開(kāi)發(fā)告訴我，他們?cè)跍y(cè)試系統(tǒng)的時(shí)候，會(huì)經(jīng)常有連接MYSQL的連接被踢掉。具體給我的解釋是，JAVA的緩沖池連接MYSQL 保持連接，但再次使用的時(shí)候，報(bào)連接錯(cuò)誤。

對(duì)應(yīng)應(yīng)用程序的報(bào)錯(cuò)的時(shí)間點(diǎn)，查了一下 PROXYSQL  和 MYSQL 的錯(cuò)誤日志，的確是有相關(guān)的錯(cuò)誤。

PROXYSQL 錯(cuò)誤日志

MYSQL 的錯(cuò)誤日志

那么問(wèn)題來(lái)了，到底為什么會(huì) got timeout reading communication packets。

DBER可以冠冕堂皇的告知，這是JAVA 的問(wèn)題，不是數(shù)據(jù)庫(kù)的問(wèn)題，但是如果作為 Architector of Databases,這樣的回答的確是遭恨。

所以必須搞清楚到底是怎么回事，故事就開(kāi)始了。首先JAVA 程序是有緩沖池來(lái)連接到 MYSQL 的 ProxySQL 的，而ProxySQL 作為MYSQL 的中間件和緩沖，會(huì)將JAVA的連接轉(zhuǎn)接到 MYSQL （MGR  MTS）的主節(jié)點(diǎn)。

分析問(wèn)題的一步步來(lái)，我們先從MYSQL 這個(gè)根上來(lái)

從MYSQL 的角度來(lái)說(shuō)，產(chǎn)生 Aborted_clients 和 Aborted_connects 有三個(gè)原因。

1  客戶(hù)端的連接，在MYSQL中被意外的終止了，至于這個(gè)意外是什么，有可能是當(dāng)前的連接被DBA 使用KILL 終止了，或者其他的PT-KILL工具之類(lèi)的方式，讓你的連接停掉了。

2 MYSQL 中的兩個(gè)參數(shù)， wait_timeout 和 interactive_timeout ，wait_timeout 是如果連接處于 idle的狀態(tài)多長(zhǎng)時(shí)間，這個(gè)連接就會(huì)被踢掉。wait_timeout 和 interactive_timeout

wait_timeout 是你的連接的idle（空閑的時(shí)間），超過(guò)多少時(shí)間就被系統(tǒng)KILL 掉

interactive_timeout 是在程序和數(shù)據(jù)庫(kù)交互中，的間隔時(shí)間，如果你間隔時(shí)間較長(zhǎng)，讓數(shù)據(jù)庫(kù)等的不耐煩了，就給你清理掉你的連接的線(xiàn)程。

程序員可能會(huì)問(wèn)，WHY， 這主要是每個(gè)連接都會(huì)HOLD住一定的內(nèi)存，例如 sort buffer join buffer 之類(lèi)的，如果這些BUFFER 初始的時(shí)候就給的挺大，那后面如果連接太多，系統(tǒng)就可能OOM， 所以系統(tǒng)必須管管那些不負(fù)責(zé)的連接，光知道開(kāi)，不知道關(guān)。

那如何來(lái)確認(rèn)你現(xiàn)在的MYSQL 的連接數(shù)，這里設(shè)置都是 1800秒，也就是30分鐘。

說(shuō)完這里，繼續(xù)說(shuō)PROXYSQL， 作為目前最好的開(kāi)源的MYSQL 的中間件，用的人不少。

其實(shí)proxysql 也是有線(xiàn)程池的，我目前的PROXYSQL 就有一個(gè)主34個(gè)子線(xiàn)程組成。

而proxysql 中的連接池也是保存空閑連接的，而多長(zhǎng)時(shí)間PROXYSQL 會(huì)進(jìn)行一個(gè)ping 保持與MYSQL之間的連接，的時(shí)間是通過(guò) mysql-ping_interval_server_msec 來(lái)進(jìn)行。

而mysql-connection_max_age_ms 是當(dāng)空連接在沒(méi)有任何會(huì)話(huà)使用的情況下，空閑的時(shí)間超過(guò)了 mysql-connection_max_age_ms 的設(shè)置后PROXYSQL 會(huì)自動(dòng)關(guān)閉這個(gè)連接。

mysql-ping_timeout_server 則是PROXYSQL 為了維持和后端的空閑連接，每隔一段時(shí)間來(lái)發(fā)送PING 一次得到回復(fù)超時(shí)的時(shí)間

寫(xiě)到這里，估計(jì)能送網(wǎng)上BAIDU到很多，關(guān)于這樣的問(wèn)題，而解決這樣問(wèn)題的方法，大部分是修改MYSQL的 兩個(gè)timeout 的時(shí)間，默認(rèn)為28800秒也就是 8個(gè)小時(shí)，他們建議將時(shí)間改為 31536000 秒，好吧我不打人，這樣的程序員每月能賺2000塊在北京都是多給。

最后我這個(gè)非JAVA Developer GOOGLE 出的解決方案是

在配置Druid DatasourceStat 

1 需要配置

validationQuery: select 1  (這樣的語(yǔ)句去訪(fǎng)問(wèn)數(shù)據(jù)庫(kù)避免引起性能的消耗）

testWhileIdle: true

timeBetweenEvictionRunsMillis: 的設(shè)置一定要小于 mysql 或者 proxysql 的 timeout 值

我這里 timeBetweenEvictionRunMills 的值應(yīng)該是小于 3分鐘。

到此 解決Communications link failure 的問(wèn)題，告知段落，到目前為止還沒(méi)有新的錯(cuò)誤告訴我，阿彌陀佛。

上述就是小編為大家分享的MYSQL 以及JAVA 連接錯(cuò)誤的示例分析了，如果剛好有類(lèi)似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識(shí)，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。