在Centos上部署項目發現一個奇怪的問題,數據庫鏈接一直拋異常。因而花了兩個小時搜了各類數據庫鏈接異常致使的緣由,最終問題得以解決。同時,把解決過程當中蒐集到的異常信息彙總一下,當你們遇到相似的問題時,給你們以思路。必須珍藏。html
先來講說我遇到的問題。項目中遇到的問題很奇怪,在Centos上安裝了Mysql數據庫,項目使用的是Spring Boot。java
項目在本地啓動鏈接服務器數據庫正常、本地數據庫客戶端鏈接服務器數據庫正常、服務器本地鏈接client鏈接數據庫正常。惟獨把項目部署到服務器上啓動時拋出異常。mysql
異常信息大概(當時未保留異常信息)以下:sql
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
幾乎嘗試了網絡上全部的解決方案均無效。漸漸開始懷疑是JDK在做怪。本地使用的JDK版本是1.8.0_151,服務器使用的是1.8.0.242,理論上是沒有影響的。數據庫
因而把服務器上的jdk卸載,從官網下載了安裝包從新安裝了1.8.0_241,數據庫鏈接的問題消失了。apache
後來仔細一想,不是小版本號的問題,而是安裝JDK的版本問題,本機安裝的JDK是從Oracle官網下載的,而服務器上存儲爲了省事直接使用yum命令安裝的。而centos上默認給安裝了OpenJDK。咱們知道,從jdk7以後,JDK和OpenJDK屬於兩個不一樣受權協議的版本,而OpenJDK源代碼不完整、OpenIDK只包含最精簡的JDK。centos
下面分享一下搜索上述異常過程當中發現的其餘緣由致使相似的異常的狀況及解決方案。服務器
問題現象與上述同樣,除了服務器部署應用沒法鏈接服務器以外,其餘方式均可以鏈接數據庫。微信
致使問題的緣由是:服務器有兩塊磁盤,中間執行過mv命令,將數據庫的存儲內容進行了移動操做,同時修改了datadir指向新的目錄。網絡
結果:用JAVA程序本地鏈接失敗,拋出org.apache.commons.dbcp.SQLNestedException: Cannot create PoolableConnectionFactory (Communications link failure 異常。
解決方案:修改了datadir相應配置以後,要覈查一下mysql.sock文件路徑的配置。默認會在/var/lib/mysql/mysql.sock或/temp/mysql.sock。而後,統一修改全部的端([client]、[mysql]、[mysqld]等)均使用統一路徑。
若是一次信息中還出現以下異常信息:
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鏈接的問題。網絡是有朋友升級到jdk1.8以後出現上述異常。
解決方案:刪掉SSLv3。在JAVA_HOME/jre/lib/security/java.security文件中找到jdk.tls.disabledAlgorithns=SSLv3,……相關的配置,刪掉SSLv3部分。刪掉SSLv3就是容許SSL調用。
針對SSL鏈接的問題,還有一種狀況就是Mysql使用SSL鏈接。關於如何配置可參看該文章:https://www.cnblogs.com/maggi...。
這種狀況是網上主流的信息,有大量的文章,但每每都沒有說明具體的場景:應用程序使用過程當中出現相似上述異常,注意這裏是使用過程當中,而不是啓動拋異常。
致使使用過程當中出現異常的緣由是:Mysql服務器默認的「wait_timeout」是8小時(28800秒),也就是一個connection空閒(沒有活動)超過8個小時,Mysql將自動斷開該connection。而鏈接池卻認爲該鏈接仍是有效的(由於並未校驗鏈接的有效性),當應用申請使用該鏈接時,就會致使上面的報錯。
解決方案:修改my.ini配置,增長超時時間或在鏈接url中添加「&autoReconnect=true」。
在port=3306下面添加以下配置:
wait_timeout=31536000 interactive_timeout=31536000
而後重啓MySQL。
這種狀況也有多是數據庫鏈接池maxIdleTime配置致使的。
<!-- 最大空閒時間,60秒內未使用則鏈接被丟棄。若爲0則永不丟棄。Default: 0 --> <property name="maxIdleTime" value="0"></property>
因爲mysql的鏈接空閒超過8個小時就關閉了,可是鏈接池卻永不丟棄鏈接,認爲該鏈接仍是有效的(由於並未校驗鏈接的有效性),當應用申請使用該鏈接時,就會致使上面的報錯。
解決方法:將value設置爲20。
固然,關於MySQL鏈接出現相似異常還有其餘不少緣由:
<center>程序新視界:精彩和成長都不容錯過</center>