MySQL中異常的客戶端連接怎么處理

這篇文章主要介紹MySQL中異常的客戶端連接怎么處理，文中介紹的非常詳細(xì)，具有一定的參考價(jià)值，感興趣的小伙伴們一定要看完！

背景1:
程序反饋數(shù)據(jù)庫(kù)出現(xiàn)了max_connection的錯(cuò)誤, 導(dǎo)致client無(wú)法連接到db;
根據(jù)程序的說(shuō)法, 使用大量的連接是歷史遺留問(wèn)題, 遂調(diào)高了max_connection的參數(shù);

背景2:
另外一個(gè)業(yè)務(wù)的程序發(fā)現(xiàn)數(shù)據(jù)庫(kù)中出現(xiàn)了一些連接時(shí)間很長(zhǎng)的sleep連接, 但是應(yīng)用層已經(jīng)把所有的進(jìn)程全部重啟了;
如截圖:


10s多的是重啟后新建的連接, 3000左右的是異常鏈接;

場(chǎng)景:
未搭建復(fù)現(xiàn)場(chǎng)景;

分析:
第一時(shí)間考慮的就是應(yīng)用服務(wù)器上還有遺漏的進(jìn)程沒(méi)有關(guān)閉, 所以導(dǎo)致了這些連接一直保持著;
程序在檢查之后一再保證確實(shí)沒(méi)有連接數(shù)據(jù)庫(kù)的進(jìn)程以后, 開(kāi)始順著網(wǎng)絡(luò)鏈路進(jìn)行分析;

首先讓程序停掉了應(yīng)用層的所有進(jìn)程, 然后發(fā)現(xiàn)MySQL上確實(shí)只留下了持續(xù)好幾千秒的sleep連接;
在DB的服務(wù)器上也能看到EST的TCP/IP連接, 確認(rèn)了連接還是存在的;
然后檢查了MySQL前端的haproxy服務(wù)器, 比對(duì)了一下端口, 也找到了haproxy上的連接;
反查haproxy的連接信息, 找到了應(yīng)用服務(wù)器的IP和對(duì)應(yīng)的端口, 如截圖:



奇怪的是, 應(yīng)用服務(wù)器上并沒(méi)有端口38710的這些信息, 新創(chuàng)建的端口都已經(jīng)到48000以后去了;
那么haproxy上, 這些與不存在端口的連接到底是什么原理?

和網(wǎng)絡(luò)部分的同事說(shuō)明情況以后, 最終給出了一個(gè)解釋:
client在連接DB的時(shí)候會(huì)經(jīng)由LVS轉(zhuǎn)發(fā)到haproxy, 其中LVS的超時(shí)時(shí)間設(shè)置比haproxy短;
因此client在保持空閑一段時(shí)間以后, 再訪問(wèn)LVS時(shí), LVS會(huì)告知client重新向haproxy發(fā)起新的連接,
邇haproxy上舊的連接因?yàn)檫€沒(méi)有到haproxy的超時(shí)時(shí)間, 所以也沒(méi)有斷開(kāi), 那么在查詢的時(shí)候就會(huì)出現(xiàn)這種沒(méi)有源頭的鏈接;

處理方式:
在發(fā)現(xiàn)了這個(gè)問(wèn)題的haproxy實(shí)例上, 調(diào)整了haproxy的超時(shí)時(shí)間, 比LVS略高, 之后的幾天內(nèi), 這種連接不再出現(xiàn);
且haproxy斷開(kāi)連接時(shí), MySQL的error log中出現(xiàn)了一些NOTE提醒有連接被斷開(kāi)了;

背景2中, 其實(shí)也是這個(gè)原因, 導(dǎo)致了在MySQL端堆積了大量的sleep連接, 結(jié)果把可用的connection都擠占了, 導(dǎo)致client無(wú)法再連接DB;
統(tǒng)一修改了haproxy的超時(shí)時(shí)間以后, 這種現(xiàn)象不再出現(xiàn), 問(wèn)題解決~

以上是“MySQL中異常的客戶端連接怎么處理”這篇文章的所有內(nèi)容，感謝各位的閱讀！希望分享的內(nèi)容對(duì)大家有幫助，更多相關(guān)知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道！