MySQL數(shù)據(jù)庫(kù)連接異常匯總（值得收藏）
在Centos上部署項(xiàng)目發(fā)現(xiàn)一個(gè)奇怪的問(wèn)題，數(shù)據(jù)庫(kù)連接一直拋異常。于是花了兩個(gè)小時(shí)搜了各種數(shù)據(jù)庫(kù)連接異常導(dǎo)致的原因，最終問(wèn)題得以解決。同時(shí)，把解決過(guò)程中搜集到的異常信息匯總一下，當(dāng)大家遇到類似的問(wèn)題時(shí)，給大家以思路。必須珍藏。
問(wèn)題現(xiàn)象
先來(lái)說(shuō)說(shuō)我遇到的問(wèn)題。項(xiàng)目中遇到的問(wèn)題很奇怪，在Centos上安裝了Mysql數(shù)據(jù)庫(kù)，項(xiàng)目使用的是Spring Boot。
項(xiàng)目在本地啟動(dòng)連接服務(wù)器數(shù)據(jù)庫(kù)正常、本地?cái)?shù)據(jù)庫(kù)客戶端連接服務(wù)器數(shù)據(jù)庫(kù)正常、服務(wù)器本地連接client連接數(shù)據(jù)庫(kù)正常。唯獨(dú)把項(xiàng)目部署到服務(wù)器上啟動(dòng)時(shí)拋出異常。
異常信息大概（當(dāng)時(shí)未保留異常信息）如下：
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
The last packet sent successfully to the server was 0 milliseconds ago. The driver has not received any packets from the server.
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at com.mysql.jdbc.Util.handleNewInstance(Util.java:425)
at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:989)
at com.mysql.jdbc.MysqlIO.<init>(MysqlIO.java:341)
at com.mysql.jdbc.ConnectionImpl.coreConnect(ConnectionImpl.java:2196)
at com.mysql.jdbc.ConnectionImpl.connectOneTryOnly(ConnectionImpl.java:2229)
at com.mysql.jdbc.ConnectionImpl.createNewIO(ConnectionImpl.java:2024)
at com.mysql.jdbc.ConnectionImpl.<init>(ConnectionImpl.java:779)
at com.mysql.jdbc.JDBC4Connection.<init>(JDBC4Connection.java:47)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at com.mysql.jdbc.Util.handleNewInstance(Util.java:425)
at com.mysql.jdbc.ConnectionImpl.getInstance(ConnectionImpl.java:389)
at com.mysql.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:330)
at java.sql.DriverManager.getConnection(Unknown Source)
at java.sql.DriverManager.getConnection(Unknown Source)
at com.ad.MysqlDemo.main(MysqlDemo.java:32)
Caused by: java.net.ConnectException: Connection refused: connect
at java.net.DualStackPlainSocketImpl.connect0(Native Method)
at java.net.DualStackPlainSocketImpl.socketConnect(Unknown Source)
at java.net.AbstractPlainSocketImpl.doConnect(Unknown Source)
at java.net.AbstractPlainSocketImpl.connectToAddress(Unknown Source)
at java.net.AbstractPlainSocketImpl.connect(Unknown Source)
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.SocksSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at com.mysql.jdbc.StandardSocketFactory.connect(StandardSocketFactory.java:211)
at com.mysql.jdbc.MysqlIO.<init>(MysqlIO.java:300)
... 15 more
異常原因
幾乎嘗試了網(wǎng)絡(luò)上所有的解決方案均無(wú)效。漸漸開始懷疑是JDK在作怪。本地使用的JDK版本是1.8.0_151，服務(wù)器使用的是1.8.0.242，理論上是沒(méi)有影響的。
于是把服務(wù)器上的jdk卸載，從官網(wǎng)下載了安裝包重新安裝了1.8.0_241，數(shù)據(jù)庫(kù)連接的問(wèn)題消失了。
后來(lái)仔細(xì)一想，不是小版本號(hào)的問(wèn)題，而是安裝JDK的版本問(wèn)題，本機(jī)安裝的JDK是從Oracle官網(wǎng)下載的，而服務(wù)器上存儲(chǔ)為了省事直接使用yum命令安裝的。而centos上默認(rèn)給安裝了OpenJDK。我們知道，從jdk7之后，JDK和OpenJDK屬于兩個(gè)不同授權(quán)協(xié)議的版本，而OpenJDK源代碼不完整、OpenIDK只包含最精簡(jiǎn)的JDK。
下面分享一下搜索上述異常過(guò)程中發(fā)現(xiàn)的其他原因?qū)е骂愃频漠惓５那闆r及解決方案。
sock路徑問(wèn)題
問(wèn)題現(xiàn)象與上述一樣，除了服務(wù)器部署應(yīng)用無(wú)法連接服務(wù)器之外，其他方式都可以連接數(shù)據(jù)庫(kù)。
導(dǎo)致問(wèn)題的原因是：服務(wù)器有兩塊磁盤，中間執(zhí)行過(guò)mv命令，將數(shù)據(jù)庫(kù)的存儲(chǔ)內(nèi)容進(jìn)行了移動(dòng)操作，同時(shí)修改了datadir指向新的目錄。
結(jié)果：用JAVA程序本地連接失敗，拋出org.apache.commons.dbcp.SQLNestedException: Cannot create PoolableConnectionFactory (Communications link failure 異常。
解決方案：修改了datadir相應(yīng)配置之后，要核查一下mysql.sock文件路徑的配置。默認(rèn)會(huì)在/var/lib/mysql/mysql.sock或/temp/mysql.sock。然后，統(tǒng)一修改所有的端（[client]、[mysql]、[mysqld]等）均使用統(tǒng)一路徑。
SSL連接問(wèn)題
如果一次信息中還出現(xiàn)如下異常信息：
javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)
at sun.security.ssl.Handshaker.activate(Handshaker.java:529)
at sun.security.ssl.SSLSocketImpl.kickstartHandshake(SSLSocketImpl.java:1492)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1361)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1413)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1397)
則有可能是SSL連接的問(wèn)題。網(wǎng)絡(luò)是有朋友升級(jí)到j(luò)dk1.8之后出現(xiàn)上述異常。
解決方案：刪掉SSLv3。在JAVA_HOME/jre/lib/security/java.security文件中找到j(luò)dk.tls.disabledAlgorithns=SSLv3,……相關(guān)的配置，刪掉SSLv3部分。刪掉SSLv3就是允許SSL調(diào)用。
針對(duì)SSL連接的問(wèn)題，還有一種情況就是Mysql使用SSL連接。關(guān)于如何配置可參看該文章：http://www.fzitv.net/article/100432.htm。
數(shù)據(jù)庫(kù)連接超時(shí)
這種情況是網(wǎng)上主流的信息，有大量的文章，但往往都沒(méi)有說(shuō)明具體的場(chǎng)景：應(yīng)用程序使用過(guò)程中出現(xiàn)類似上述異常，注意這里是使用過(guò)程中，而不是啟動(dòng)拋異常。
導(dǎo)致使用過(guò)程中出現(xiàn)異常的原因是：Mysql服務(wù)器默認(rèn)的“wait_timeout”是8小時(shí)（28800秒），也就是一個(gè)connection空閑（沒(méi)有活動(dòng)）超過(guò)8個(gè)小時(shí)，Mysql將自動(dòng)斷開該connection。而連接池卻認(rèn)為該連接還是有效的(因?yàn)椴⑽葱ｒ?yàn)連接的有效性)，當(dāng)應(yīng)用申請(qǐng)使用該連接時(shí)，就會(huì)導(dǎo)致上面的報(bào)錯(cuò)。
解決方案：修改my.ini配置，增加超時(shí)時(shí)間或在連接url中添加“&autoReconnect=true”。
在port=3306下面添加如下配置：
wait_timeout=31536000
interactive_timeout=31536000
然后重啟MySQL。
這種情況也有可能是數(shù)據(jù)庫(kù)連接池maxIdleTime配置導(dǎo)致的。
<!-- 最大空閑時(shí)間,60秒內(nèi)未使用則連接被丟棄。若為0則永不丟棄。Default: 0 --> <property name="maxIdleTime" value="0"></property>
由于mysql的連接空閑超過(guò)8個(gè)小時(shí)就關(guān)閉了，但是連接池卻永不丟棄連接，認(rèn)為該連接還是有效的(因?yàn)椴⑽葱ｒ?yàn)連接的有效性)，當(dāng)應(yīng)用申請(qǐng)使用該連接時(shí)，就會(huì)導(dǎo)致上面的報(bào)錯(cuò)。
解決方法：將value設(shè)置為20。
其他原因
當(dāng)然，關(guān)于MySQL連接出現(xiàn)類似異常還有其他很多原因：
- 數(shù)據(jù)庫(kù)賬戶訪問(wèn)權(quán)限問(wèn)題：指定ip和賬戶授權(quán)；
- 網(wǎng)絡(luò)權(quán)限問(wèn)題：防火墻是否開啟對(duì)應(yīng)的訪問(wèn)權(quán)限；
- 端口問(wèn)題：訪問(wèn)的端口是否正確，端口是否開啟防火墻權(quán)限；
- 賬戶密碼問(wèn)題：賬戶密碼錯(cuò)誤或賬戶沒(méi)有指定ip的訪問(wèn)權(quán)限；
- 數(shù)據(jù)庫(kù)驅(qū)動(dòng)問(wèn)題：數(shù)據(jù)庫(kù)驅(qū)動(dòng)與數(shù)據(jù)庫(kù)對(duì)應(yīng)版本不匹配。
- 網(wǎng)絡(luò)穩(wěn)定問(wèn)題：網(wǎng)絡(luò)不穩(wěn)定導(dǎo)致的問(wèn)題。
- 數(shù)據(jù)庫(kù)連接池問(wèn)題：數(shù)據(jù)庫(kù)連接池配置過(guò)大，導(dǎo)致mysql默認(rèn)連接數(shù)不夠的問(wèn)題。
- ipv4與ipv6的問(wèn)題。
以上就是MySQL數(shù)據(jù)庫(kù)連接異常匯總的詳細(xì)內(nèi)容，更多關(guān)于MySQL數(shù)據(jù)庫(kù)連接異常的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！
相關(guān)文章
MySQL之Field‘***’doesn’t have a default value錯(cuò)誤解決辦法
這篇文章主要介紹了MySQL之Field‘***’doesn’t have a default value錯(cuò)誤解決辦法,需要的朋友可以參考下2015-04-04
數(shù)據(jù)分布特點(diǎn)，決定了空間壓縮的效率，如果存入的數(shù)據(jù)的重復(fù)率較高，其壓縮率就會(huì)較高；通常情況下字符類型數(shù)據(jù)(CHAR, VARCHAR, TEXT or BLOB )具有較高的壓縮率，而一些二進(jìn)制數(shù)據(jù)或者一些已經(jīng)壓縮過(guò)的數(shù)據(jù)的壓縮率不會(huì)很好2017-06-06
mysql SELECT FOR UPDATE語(yǔ)句使用示例
本文介紹在mysql中使用mysql SELECT FOR UPDATE 語(yǔ)句時(shí)的一些問(wèn)題與解決辦法2013-11-11
這篇文章主要介紹了MySQL鎖機(jī)制與用法,較為詳細(xì)的分析了mysql鎖機(jī)制的分類、原理及相關(guān)使用技巧,需要的朋友可以參考下2018-04-04
這篇文章主要介紹了MySQL查詢結(jié)果處理方式,具有很好的參考價(jià)值,希望對(duì)大家有所幫助,如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2024-04-04
mysql存儲(chǔ)過(guò)程與函數(shù)學(xué)習(xí)與實(shí)踐方式
下面小編就為大家分享一篇mysql存儲(chǔ)過(guò)程與函數(shù)學(xué)習(xí)與實(shí)踐方式，具有很好的參考價(jià)值，希望對(duì)大家有所幫助。一起跟隨小編過(guò)來(lái)看看吧2017-12-12
Mysql跨表更新 多表update sql語(yǔ)句總結(jié)
Mysql跨表更新一直是大家所關(guān)心的話題，本文介紹mysql多表 update在實(shí)踐中幾種不同的寫法，需要的朋友可以參考下2012-12-12
MySQL使用集合函數(shù)進(jìn)行查詢操作實(shí)例詳解
這篇文章主要介紹了MySQL使用集合函數(shù)進(jìn)行查詢操作,結(jié)合實(shí)例形式詳細(xì)分析了MySQL使用集合函數(shù)進(jìn)行的運(yùn)算與查詢操作使用技巧,需要的朋友可以參考下2018-06-06
本篇文章主要介紹了MySQL多表鏈接查詢核心優(yōu)化，數(shù)據(jù)庫(kù)對(duì)數(shù)據(jù)表的多表查詢是必不可少的，所以涉及到性能優(yōu)化，有需要的可以了解一下。2016-11-11
MySQL數(shù)據(jù)庫(kù)以體積小、速度快、總體擁有成本低等優(yōu)點(diǎn),深受廣大中小企業(yè)的喜愛(ài)，下面這篇文章主要給大家介紹了關(guān)于MySQL中常用工具的相關(guān)資料，需要的朋友們可以參考學(xué)習(xí)，下面來(lái)一起看看吧。2017-09-09