MySQL數(shù)據(jù)庫連接異常匯總(值得收藏)
在Centos上部署項目發(fā)現(xiàn)一個奇怪的問題,數(shù)據(jù)庫連接一直拋異常。于是花了兩個小時搜了各種數(shù)據(jù)庫連接異常導致的原因,最終問題得以解決。同時,把解決過程中搜集到的異常信息匯總一下,當大家遇到類似的問題時,給大家以思路。必須珍藏。
問題現(xiàn)象
先來說說我遇到的問題。項目中遇到的問題很奇怪,在Centos上安裝了Mysql數(shù)據(jù)庫,項目使用的是Spring Boot。
項目在本地啟動連接服務器數(shù)據(jù)庫正常、本地數(shù)據(jù)庫客戶端連接服務器數(shù)據(jù)庫正常、服務器本地連接client連接數(shù)據(jù)庫正常。唯獨把項目部署到服務器上啟動時拋出異常。
異常信息大概(當時未保留異常信息)如下:
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)絡上所有的解決方案均無效。漸漸開始懷疑是JDK在作怪。本地使用的JDK版本是1.8.0_151,服務器使用的是1.8.0.242,理論上是沒有影響的。
于是把服務器上的jdk卸載,從官網(wǎng)下載了安裝包重新安裝了1.8.0_241,數(shù)據(jù)庫連接的問題消失了。
后來仔細一想,不是小版本號的問題,而是安裝JDK的版本問題,本機安裝的JDK是從Oracle官網(wǎng)下載的,而服務器上存儲為了省事直接使用yum命令安裝的。而centos上默認給安裝了OpenJDK。我們知道,從jdk7之后,JDK和OpenJDK屬于兩個不同授權(quán)協(xié)議的版本,而OpenJDK源代碼不完整、OpenIDK只包含最精簡的JDK。
下面分享一下搜索上述異常過程中發(fā)現(xiàn)的其他原因?qū)е骂愃频漠惓5那闆r及解決方案。
sock路徑問題
問題現(xiàn)象與上述一樣,除了服務器部署應用無法連接服務器之外,其他方式都可以連接數(shù)據(jù)庫。
導致問題的原因是:服務器有兩塊磁盤,中間執(zhí)行過mv命令,將數(shù)據(jù)庫的存儲內(nèi)容進行了移動操作,同時修改了datadir指向新的目錄。
結(jié)果:用JAVA程序本地連接失敗,拋出org.apache.commons.dbcp.SQLNestedException: Cannot create PoolableConnectionFactory (Communications link failure 異常。
解決方案:修改了datadir相應配置之后,要核查一下mysql.sock文件路徑的配置。默認會在/var/lib/mysql/mysql.sock或/temp/mysql.sock。然后,統(tǒng)一修改所有的端([client]、[mysql]、[mysqld]等)均使用統(tǒng)一路徑。
SSL連接問題
如果一次信息中還出現(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ǎng)絡是有朋友升級到jdk1.8之后出現(xiàn)上述異常。
解決方案:刪掉SSLv3。在JAVA_HOME/jre/lib/security/java.security文件中找到jdk.tls.disabledAlgorithns=SSLv3,……相關(guān)的配置,刪掉SSLv3部分。刪掉SSLv3就是允許SSL調(diào)用。
針對SSL連接的問題,還有一種情況就是Mysql使用SSL連接。關(guān)于如何配置可參看該文章:https://www.jb51.net/article/100432.htm。
數(shù)據(jù)庫連接超時
這種情況是網(wǎng)上主流的信息,有大量的文章,但往往都沒有說明具體的場景:應用程序使用過程中出現(xiàn)類似上述異常,注意這里是使用過程中,而不是啟動拋異常。
導致使用過程中出現(xiàn)異常的原因是:Mysql服務器默認的“wait_timeout”是8小時(28800秒),也就是一個connection空閑(沒有活動)超過8個小時,Mysql將自動斷開該connection。而連接池卻認為該連接還是有效的(因為并未校驗連接的有效性),當應用申請使用該連接時,就會導致上面的報錯。
解決方案:修改my.ini配置,增加超時時間或在連接url中添加“&autoReconnect=true”。
在port=3306下面添加如下配置:
wait_timeout=31536000interactive_timeout=31536000
然后重啟MySQL。
這種情況也有可能是數(shù)據(jù)庫連接池maxIdleTime配置導致的。
<!-- 最大空閑時間,60秒內(nèi)未使用則連接被丟棄。若為0則永不丟棄。Default: 0 --> <property name='maxIdleTime' value='0'></property>
由于mysql的連接空閑超過8個小時就關(guān)閉了,但是連接池卻永不丟棄連接,認為該連接還是有效的(因為并未校驗連接的有效性),當應用申請使用該連接時,就會導致上面的報錯。
解決方法:將value設置為20。
其他原因
當然,關(guān)于MySQL連接出現(xiàn)類似異常還有其他很多原因:
數(shù)據(jù)庫賬戶訪問權(quán)限問題:指定ip和賬戶授權(quán); 網(wǎng)絡權(quán)限問題:防火墻是否開啟對應的訪問權(quán)限; 端口問題:訪問的端口是否正確,端口是否開啟防火墻權(quán)限; 賬戶密碼問題:賬戶密碼錯誤或賬戶沒有指定ip的訪問權(quán)限; 數(shù)據(jù)庫驅(qū)動問題:數(shù)據(jù)庫驅(qū)動與數(shù)據(jù)庫對應版本不匹配。 網(wǎng)絡穩(wěn)定問題:網(wǎng)絡不穩(wěn)定導致的問題。 數(shù)據(jù)庫連接池問題:數(shù)據(jù)庫連接池配置過大,導致mysql默認連接數(shù)不夠的問題。 ipv4與ipv6的問題。以上就是MySQL數(shù)據(jù)庫連接異常匯總的詳細內(nèi)容,更多關(guān)于MySQL數(shù)據(jù)庫連接異常的資料請關(guān)注好吧啦網(wǎng)其它相關(guān)文章!
相關(guān)文章:
1. Oracle數(shù)據(jù)庫網(wǎng)絡與安全常見問題集錦2. 詳解Mysql 函數(shù)調(diào)用優(yōu)化3. 由淺至深講解Oracle數(shù)據(jù)庫 B-tree索引4. MySQL按指定字符合并以及拆分實例教程5. 實例驗證MySQL|update字段為相同的值是否會記錄binlog6. 分享Sql Server 存儲過程使用方法7. MySQL/MariaDB 如何實現(xiàn)數(shù)據(jù)透視表的示例代碼8. oracle19c卸載教程的超詳細教程9. MySQL 字符串函數(shù):字符串截取10. 解決MyBatis中Enum字段參數(shù)解析問題
