建站
咨詢
售后
建站咨詢
新聞中心
前言
最近遇到在將本地的項(xiàng)目部署到服務(wù)器上之后遇到的一個(gè)奇怪問(wèn)題：
成都創(chuàng)新互聯(lián)公司是一家專業(yè)提供萬(wàn)源企業(yè)網(wǎng)站建設(shè),專注與成都網(wǎng)站建設(shè)、網(wǎng)站設(shè)計(jì)、H5建站、小程序制作等業(yè)務(wù)。10年已為萬(wàn)源眾多企業(yè)、政府機(jī)構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專業(yè)網(wǎng)站設(shè)計(jì)公司優(yōu)惠進(jìn)行中。
在部署完成后，網(wǎng)站當(dāng)時(shí)可以正常工作，但是第二天訪問(wèn)網(wǎng)站的時(shí)候卻會(huì)遇到一個(gè)500 Server Error。
從日志中可以看出是MySQL數(shù)據(jù)庫(kù)出現(xiàn)了異常：
翻譯如下:
最后一個(gè)數(shù)據(jù)包在 83827560 ms 之前被成功接收，最后一個(gè)數(shù)據(jù)包在83827560 ms 之前被成功發(fā)送。比服務(wù)的配置參數(shù)wait_timeout的值要長(zhǎng)。
日志中給出的建議如下：
翻譯如下：
你應(yīng)考慮在程序中進(jìn)行數(shù)據(jù)庫(kù)操作之前檢驗(yàn)數(shù)據(jù)庫(kù)連接的有效性或者將數(shù)據(jù)庫(kù)的autoReconnect屬性設(shè)置為true來(lái)避免這個(gè)問(wèn)題
關(guān)于wait_timeout和autoReconnect下面我們會(huì)依次分析介紹！
原因分析
我們進(jìn)入mysql的命令行查詢超時(shí)時(shí)間：
28800單位是秒轉(zhuǎn)化成小時(shí)就是8小時(shí)，看出MySQL的默認(rèn)設(shè)置，當(dāng)一個(gè)連接的空閑時(shí)間超過(guò)8小時(shí)后，MySQL就會(huì)斷開(kāi)該連接。
所以發(fā)現(xiàn)問(wèn)題出在如果超過(guò)這個(gè)wait_timeout時(shí)間(默認(rèn)是8小時(shí))對(duì)數(shù)據(jù)庫(kù)沒(méi)有任何操作，那么MySQL會(huì)自動(dòng)關(guān)閉數(shù)據(jù)庫(kù)連接以節(jié)省資源。
數(shù)據(jù)庫(kù)連接自動(dòng)斷開(kāi)的問(wèn)題確實(shí)是在第二天發(fā)生了，也就是在一個(gè)晚上沒(méi)有對(duì)數(shù)據(jù)庫(kù)進(jìn)行操作(顯然超過(guò)了8小時(shí))的情況下發(fā)生的這個(gè)問(wèn)題。
大家用命令show processlist; 可以查看Sleep狀態(tài)的進(jìn)程Sleep，同時(shí)可以看到每個(gè)進(jìn)程Sleep多久了：
下面介紹下解決和優(yōu)化辦法！
解決方法
1. autoReconnect
這個(gè)參數(shù)表示在mysql超時(shí)斷開(kāi)連接后會(huì)自動(dòng)重新連接，配置的話，只需要在連接mysql的語(yǔ)句寫上autoReconnect=true：
jdbc:mysql://127.0.0.1:3306/stock_tweet?autoReconnect=true
下面是MySQL官網(wǎng)對(duì)autoReconnect的解釋:
同時(shí)可以看到官網(wǎng)不推薦使用這個(gè)參數(shù)，因?yàn)樗幸恍└弊饔茫唧w介紹下：
- 原有連接上的事務(wù)將會(huì)被回滾，事務(wù)的提交模式將會(huì)丟失；
- 原有連接持有的表的鎖將會(huì)全部釋放；
- 原有連接關(guān)聯(lián)的會(huì)話Session將會(huì)丟失，重新恢復(fù)的連接關(guān)聯(lián)的將會(huì)是一個(gè)新的會(huì)話Session；
- 原有連接定義的用戶變量將會(huì)丟失；
- 原有連接定義的預(yù)編譯SQL將會(huì)丟失；
- 原有連接失效，新的連接恢復(fù)后，MySQL將會(huì)使用新的記錄行來(lái)存儲(chǔ)連接中的性能數(shù)據(jù)；
2. 修改配置
涉及到兩個(gè)配置參數(shù)interactive_timeout和wait_timeout：
- wait_timeout 指的是mysql在關(guān)閉一個(gè)非交互的連接之前所要等待的秒數(shù)
- interactive_time 指的是mysql在關(guān)閉一個(gè)交互的連接之前所要等待的秒數(shù)
對(duì)于交互和非交互連接，說(shuō)得直白一點(diǎn)就是，通過(guò)mysql客戶端連接數(shù)據(jù)庫(kù)是交互式連接，通過(guò)jdbc連接數(shù)據(jù)庫(kù)是非交互式連接。
配置方法：
(1) 會(huì)話方式
msyql> set global wait_timeout=2880000;
msyql> set global interactive_timeout=2880000;
這種方式只對(duì)當(dāng)前會(huì)話生效.
(2) 修改配置文件方式
修改/etc/my.cnf文件，在 [mysqld] 節(jié)中設(shè)置：
之后再重啟下服務(wù)器就好了！
注意：
- 將wait_timeout這個(gè)值設(shè)置得大了，可能會(huì)導(dǎo)致空閑連接過(guò)多。
- 如果你的MySQL Server有大量的閑置連接，他們不僅會(huì)白白消耗內(nèi)存，而且如果連接一直在累加而不斷開(kāi)，最終肯定會(huì)達(dá)到MySQL Server的連接上限數(shù)，這會(huì)報(bào)'too many connections'的錯(cuò)誤。
3. 連接池配置
因?yàn)檫B接池的配置也會(huì)影響項(xiàng)目和MySQL的連接，所以也需要對(duì)數(shù)據(jù)庫(kù)連接池的一些配置做一定修改
我們以Spring Boot 2.0默認(rèn)的數(shù)據(jù)庫(kù)連接池HikariCP為例
主要是下面這幾個(gè)配置
(1) maximum-pool-size：
最大連接數(shù)，超過(guò)這個(gè)數(shù)，新的數(shù)據(jù)庫(kù)訪問(wèn)線程會(huì)被阻，缺省值：10。
常見(jiàn)的錯(cuò)誤是設(shè)置一個(gè)太大的值，連接數(shù)多反而性能下降。
參考計(jì)算公式是：
#core_count：CPU個(gè)數(shù)，effective_spindle_count:硬盤個(gè)數(shù)
connections = ((core_count * 2) + effective_spindle_count)
例如：一個(gè)4核，1塊硬盤的服務(wù)器，連接數(shù) = (4 * 2) + 1 = 9，湊個(gè)整數(shù)，10就可以了。
(2) minimum-idle：
最小的連接數(shù)目。
(3) max-lifetime:
最大的連接時(shí)間，用來(lái)設(shè)置一個(gè)connection在連接池中的存活時(shí)間。
缺?。?0分鐘。強(qiáng)烈建議設(shè)置比數(shù)據(jù)庫(kù)超時(shí)時(shí)長(zhǎng)少一點(diǎn)(MySQL的wait_timeout參數(shù)一般為8小時(shí))。
(4) idle-timeout:
一個(gè)連接idle狀態(tài)的最長(zhǎng)時(shí)間，超時(shí)則被釋放。
文章標(biāo)題：MySQL為什么莫名其妙的斷開(kāi)連接以及解決方案！
標(biāo)題網(wǎng)址：http://www.dlmjj.cn/article/dpsghpo.html
