CentOS7-MySQL排坑歷程

PS：若是以爲文章有什麼地方寫錯了，哪裏寫得很差，或者有什麼建議，歡迎指點。

1、報錯及原由

今天在 CentOS7 中安裝了 mysql5.7，而後爲了測試數據庫環境是否配置成功，便寫了個基於 mybatis+Spring 的 java web 程序鏈接操做 mysql 數據庫，因而就一些發生了使人感到很煩的報錯和故事：

當程序涉及到關於數據庫的操做如查詢、插入等操做時，首先瀏覽器訪問會很慢，進度條一直旋轉，而後頁面會報 500 錯誤：org.mybatis.spring.MyBatisSystemException: nested exception is org.apache.ibatis.exception 。然而我在 CentOS7 服務端和 Windows 本地的 Navicat 鏈接 mysql 都沒問題。。。

2、排錯歷程

1.檢查 sql 語句

看着這彷佛是 mybatis 引發的錯誤，因此先檢查 mapper 的 xml 中 sql 語句是否有錯誤，例如參數的格式轉化、resultType 爲 JavaBean、resultMap 須要定義、JavaBean 和 dao 的引入等。

檢查中並無發現什麼問題，並且錯誤仍然存在。

2. MySql Host is blocked because of many connection errors; unblock with 'mysqladmin flush-hosts' 報錯

緣由分析：

查看 tomcat 的日誌文件，發如今報錯開始部分出現了這個錯誤。通過查詢，發現這個錯誤的 緣由 是：同一個 ip 在短期內產生太多（超過 mysql 數據庫 max_connection_errors 的最大值）中斷的數據庫鏈接而致使的阻塞。

解決方法：

進入 CentOS7 服務器：

方法一：提升容許的max_connection_errors數量（治標不治本）：

1. 進入 Mysql 數據庫查看 max_connection_errors： show variables like '%max_connection_errors%';
2. 修改 max_connection_errors 的數量爲 1000： set global max_connect_errors = 1000;
3. 查看是否修改爲功：show variables like '%max_connection_errors%';

方法二：使用 mysqladmin flush-hosts 命令清理一下 hosts 文件：

1. 查找 mysqladmin 的路徑：whereis mysqladmin
2. 執行命令，如：/usr/local/mysql5.5.35/bin/mysqladmin -uroot -pyourpwd flush-hosts

注： 方法二清理 hosts 文件，也能夠直接進入 mysql 數據庫執行命令：mysql> flush hosts;

3.com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure 異常

解決了 hosts 的問題後，在 tomcat 的日誌文件，發如今報錯開始部分又出現了這個錯誤：

com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure

The last packet successfully received from the server was 32 milliseconds ago.  The last packet sent successfully to the server was 32 milliseconds ago.
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
    at com.mysql.jdbc.Util.handleNewInstance(Util.java:425)
    at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:990)
    ......

緣由分析：

表示程序與 MySQL 通信失敗了，即鏈接失敗了。The last packet successfully received from the server was 32 milliseconds ago 表示 mysql 重連，鏈接丟失。此爲數據庫鏈接空閒回收問題，程序打開數據庫鏈接後，等待作數據庫操做時，發現鏈接被 MySQL 關閉掉了。

認爲多是鏈接等待超時問題。在 mysql 數據庫的配置中，其鏈接的等待時間（wait_timeout）缺省值爲 8 小時。在 mysql 中能夠查看：

mysql﹥ 
mysql﹥ show global variables like 'wait_timeout'; 
+---------------+---------+ 
| Variable_name | Value | 
+---------------+---------+ 
| wait_timeout | 28800 | 
+---------------+---------+ 
1 row in set (0.00 sec)

28800 seconds，也就是8小時。若是在 wait_timeout 秒期間內，數據庫鏈接(java.sql.Connection)一直處於等待狀態，mysql 就將該鏈接關閉。這時，Java 應用的鏈接池仍然合法地持有該鏈接的引用。當用該鏈接來進行數據庫操做時，就碰到上述錯誤。

MySQL 鏈接一次鏈接需求會通過 6 次「握手」方可成功，任何一次「握手」失敗均可能致使鏈接失敗。前三次握手能夠簡單理解爲 TCP 創建鏈接所必須的三次握手，MySQL 沒法控制，更多的受制於 tcp 協議的不一樣實現，後面三次握手過程超時與 connect_timeout 有關。

解決方法：

改變數據庫參數是最簡單的處理方式（修改 /etc/my.cnf 中的 wait_timeout 值），可是須要重啓數據庫，影響較大。在不修改數據庫參數的前提下，能夠作已下處理：

• 若是使用的是 jdbc ，在 jdbc url 上添加 autoReconnect=true ，如：dataSource.url=jdbc:mysql://132.231.xx.xxx:3306/shop?useUnicode=true&characterEncoding=utf8&useSSL=true&autoReconnect=true

• 若是是在 Spring 中使用 DBCP 鏈接池，在定義 datasource 增長屬性 validationQuery 和 testOnBorrow ，如：

  <bean id="vrsRankDataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
      <property name="driverClassName" value="${dataSource.driver}"/>
      <property name="url" value="${dataSource.url}"/>
      <property name="username" value="${dataSource.user}"/>
      <property name="password" value="${dataSource.password}"/>
      <property name="validationQuery" value="SELECT 1"/>
      <property name="testOnBorrow" value="true"/>
  </bean>

• 若是是在 Spring 中使用 c3p0 鏈接池，則在定義 datasource 的時候，添加屬性 testConnectionOnCheckin 和 testConnectionOnCheckout ，如：

  <bean name="cacheCloudDB" class="com.mchange.v2.c3p0.ComboPooledDataSource">
      <property name="driverClass" value="${dataSource.driver}"/>
      <property name="jdbcUrl" value="${dataSource.url}"/>
      <property name="user" value="${dataSource.user}"/>
      <property name="password" value="${dataSource.password}"/>
      <property name="initialPoolSize" value="10"/>
      <property name="maxPoolSize" value="10"/>
      <property name="testConnectionOnCheckin" value="false"/>
      <property name="testConnectionOnCheckout" value="true"/>
      <property name="preferredTestQuery" value="SELECT 1"/>
  </bean>

4. 遠程鏈接 Mysql 太慢問題

嘗試解決了一下上面的鏈接超時問題，可是發現並無什麼用，仍是會出現上面的問題。因而便懷疑是否是遠程鏈接 Mysql 太慢致使了鏈接超時？由於我在 CentOS7 服務端和 Windows 本地的 Navicat 鏈接 mysql 都沒問題。在網上查詢了下，發如今 mysql 的配置文件 /etc/my.cnf 中增長以下配置參數：

# 注意該配置是加在[mysqld]下面
[mysqld]
skip-name-resolve

而後須要重啓 mysql 服務。由於根聽說明，若是 mysql 主機查詢和解析 DNS 會致使緩慢或是有不少客戶端主機時會致使鏈接很慢。同時，請注意在增長該配置參數後，mysql的受權表中的host字段就不可以使用域名而只可以使用ip地址了，由於這是禁止了域名解析的結果。

5. 終極解決：Could not create connection to database server. Attempted reconnect 3 times. Giving up 報錯

緣由分析：

通過上面的配置後，從新測試程序，就又出現了這個錯誤。通過查詢，發現這是因爲 SSL 引發的錯誤。由於我是在 CentOS7 上使用 yum 命令新裝的 MySQL5.7，默認是沒有配置 MySQL SSL 的。

而我之前一直使用的 Ubuntu16.04 上的 mysql 數據庫，它默認是配置了 MySQL SSL 的，因此我習慣在鏈接數據庫的 jdbc 的 url 裏面加上 &useSSL=true ，即便用 SSL 加密。致使我在鏈接當前 mysql 的時候，一直鏈接不上。查看 tomcat 日誌的報錯末尾，會有以下報錯：

Caused by: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: java.security.cert.CertPathValidatorException: Path does not chain with any of the trust anchors
    at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
    at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1946)
    at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:316)
    at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:310)
    at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1639)
    at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:223)
    at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1037)
    at sun.security.ssl.Handshaker.process_record(Handshaker.java:965)
    at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1064)
    at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1367)
    at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1395)
    at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1379)
    at com.mysql.jdbc.ExportControlled.transformSocketToSSLSocket(ExportControlled.java:186)
    ... 24 more
Caused by: java.security.cert.CertificateException: java.security.cert.CertPathValidatorException: Path does not chain with any of the trust anchors
    at com.mysql.jdbc.ExportControlled$X509TrustManagerWrapper.checkServerTrusted(ExportControlled.java:302)
    at sun.security.ssl.AbstractTrustManagerWrapper.checkServerTrusted(SSLContextImpl.java:1091)
    at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1621)
    ... 32 more
Caused by: java.security.cert.CertPathValidatorException: Path does not chain with any of the trust anchors
    at sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:154)
    at sun.security.provider.certpath.PKIXCertPathValidator.engineValidate(PKIXCertPathValidator.java:80)
    at java.security.cert.CertPathValidator.validate(CertPathValidator.java:292)
    at com.mysql.jdbc.ExportControlled$X509TrustManagerWrapper.checkServerTrusted(ExportControlled.java:295)
    ... 34 more

遂恍然大悟。。。

解決方法：

在配置 JDBC URL 時使用 &useSSL=false ，即不使用 SSL 加密，配置後鏈接正常：

dataSource.url = jdbc:mysql://132.231.xx.xxx:3306/shop?useUnicode=true&characterEncoding=utf8&useSSL=false&autoReconnect=true

若是安全性較高的數據建議在 MySQL 端仍是把 SSL 配上。

3、總結

因爲 MySQL 的 SSL 問題引發了一連串的問題。因爲 SSL 加密的問題，致使程序向 mysql 的鏈接超時，而後一直向 mysql 發送鏈接，致使了同一個 ip 在短期內產生太多中斷的數據庫鏈接而致使的阻塞。

之後看報錯日誌，除了看報錯的最開始部分，也要看看報錯的結尾部分，弄很差會有一些其餘的發現的。

---

歡迎您的點贊、收藏和評論！（完）