Mysql，若是幾分鐘不用，再次操做時就會很慢

1 原由

用的是mysql， mysql是直接使用阿里雲服務器， 不是內網。 若是4分鐘左右不用，再次操做時就會很慢，但只會慢這一次，接下來又正常了，若是繼續一段時間不用，再次操做時又會慢一次。

2 形成影響

• 2.1 影響開發心情， 隔4分鐘左右， 再次操做， 用客戶端工具會卡主。
• 2.2 影響開發效率， 數據庫鏈接池中全部鏈接都出現No operations allowed after connection closed

3 排查

• 3.1 排查數據庫， 查詢mysql， wait_timeout：28800， 暫時排除
• 3.2 排查代碼， 數據庫相關的一些time設置， 網上推薦的。 暫時排除
• 3.3 排查網絡

4 重點排除網絡方面

工具方面 使用是Navicat Dbeaver idea自帶的， 都有問題， 排查工具影響

4.1 防火牆方面， 已經關閉了本地和服務器的防火牆。

4.2 查看雙方tcp鏈接狀態

本地tcp是establish狀態

5分鐘後查看服務器tcp狀態， 個人數據庫是3303端口的， 查看公網ip

查看tcp狀態

總結： 若是是本地或服務器tcp狀態是close狀態， 就能肯定是哪一方出現問題

4.3 wireshark查看

出現不少, 通常爲5次， tcp retransmission， 系統默認

tcp retransmission是由於沒有收到阿里服務器的ack確認

4.4 服務器使用tcpdump 進行抓包

正常執行sql語句，是能夠抓到包， 可是5分鐘後， 執行客戶端工具，沒監聽到任何數據。

總結： 到此得出， tcp的包中傳輸過程當中丟失了， 基於對網絡傳輸方面知識的匱乏， 首先只能排查是否公司網絡影響， 讓組員會家裏測試， 本身也回宿舍測試了一下。 仍是存在問題， 因此首先排查公司網絡的問題。

4.5 暫時解決

考慮到是是本地windows環境， tcpRetransmission默認是5次， 並隨着每次重傳而增長一倍。 tcpRetransmission是爲了保證數據傳輸的可靠性，但本着是本身電腦，而且是開發環境因此， 修改了次數。

打開註冊表 regedit
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters 右鍵新建DWORD
名稱：TcpMaxDataRetransmissions 值爲：1或2

5 問題加深

過幾天，組員發覺數據鏈接不上， 做爲組長， 我必需要解決這個問題。 首先我用其餘阿里雲服務器登錄mysql， 發現登錄正常。 其次我跑的其餘小組， 讓他們用電腦試一下， 竟然是能夠的。 原本想試着mysql， 可是怕重啓就能夠了， 重現不了場景。 因此再一次進行排查。 折騰了好久， 最後修改了端口3303， 才能正常鏈接上。 因爲公司有多臺阿里雲， 而且部署在上面的mysql， 在那段時間內， 都鏈接不上，而後其餘組又能夠鏈接的上， 因此認爲是公司網絡的緣由， 但因爲折騰了幾個小時， 又能鏈接的上了， 因此打算下次重現聯繫公司網關協助排查。

6 最終解決-Redis又出幺蛾子

過幾天Redis又忽然鏈接不上了， 本着是忽然鏈接不上， 而後其餘小組又能正常鏈接。 聯繫公司綜合部， 讓綜合部去找人看看網絡，但因爲網關有事， 暫時來不了， 只能暫時本身折騰。 忽然想到， 上次全部部署在阿里上的數據庫， 都不能鏈接， 只有一個部署在騰訊雲的服務器能夠鏈接， 會不會是阿里雲限制了， 因此馬上登錄阿里雲， 將本地公網ip加入白名單。 忽然就能連上了。

7 總結

將ip加入白名單， 以前數據庫幾分鐘不執行語句就斷開的問題也解決了。 世界都清淨了。 折騰這麼久的問題也解決了。 happy ending 可是仍是與疑惑， 首先隔壁小組都是用同樣的網絡， 公網ip也是同樣的， 爲何他們就能夠鏈接。 這是我有疑惑的， 難道是對咱們mac地址作了記錄限制了嗎， 其次阿里雲對咱們的限制， 爲何沒有想關的通告。 致使了花費了這麼多時間。