如何修復 Java 應用程式中 MySQL 的通訊鏈路故障錯誤

1. 概述

由於 MySQL 是最常用的資料庫管理系統之一，我們需要一種方法來建立 MySQL 和 Java 應用程式之間的穩定連線。通常，這是透過 MySQL Connector/J JDBC 驅動程式實現的。然而，一個常見的問題是Communications link failure錯誤，通常會拋出CommunicationsException異常。雖然錯誤訊息看起來很簡單，但其根本原因可能千差萬別。

本教學將說明如何修復使用 MySQL 的 Java 應用程式中的Communications link failure 」錯誤。首先，我們將探討該異常的涵義及其出現時機。之後，我們將分析配置問題、網路問題、MySQL 設定以及其他潛在原因。最後，我們將討論診斷問題、規避或修復該問題的不同方法。

要注意的是，我們主要指的是與 MySQL Server 5.7和8.x一起使用的 MySQL Connector/J 8.x由於較早的 Connector/J 5.1.x版本與較新的 8.x 版本之間存在一些差異，我們將在必要時在文中明確提及這些差異。

2. 理解錯誤

在嘗試解決問題之前，讓我們先了解錯誤是如何以及何時出現的。

2.1. CommunicationsException

通常，該錯誤發生在 Java 應用程式中，導致 JDBC CommunicationsEsception異常：

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.

基本上， JDBC 驅動程式嘗試與 MySQL 伺服器交換數據，但沒有數據傳輸通過。

對於 Connector/J 5.1.x ，該異常通常出現在com.mysql.jdbc.exceptions.jdbc4.CommunicationsException包下。然而，Connector/J 8.x版本將該套件更改為com.mysql.cj.jdbc.exceptions.CommunicationsException 。這種變化並不出乎意料，未來的版本可能會延續這一趨勢。

在實踐中，我們經常在以下兩種情況下遇到這種錯誤：

• 在初始連線嘗試期間
• 在已建立的連線上執行查詢時

有鑑於此，讓我們來探究一下常見原因。

2.2 常見原因

雖然錯誤本身俱有普遍性，但在生產系統中經常會出現幾個潛在問題：

• 我們的 MySQL 伺服器沒有運行
• JDBC 連線 URL 包含錯誤的主機名稱或連接埠
• 對已配置主機的 DNS 解析失敗
• MySQL 沒有監聽 TCP/IP 連接
• 防火牆或代理規則阻止資料庫流量
• 伺服器關閉空閒連接
• 應用程式耗盡可用資料庫連接
• JDBC驅動程式版本與伺服器不相容

由於多種因素都可能導致相同異常，因此診斷問題可能需要多個步驟。

3. 驗證基本連接

首先，讓我們確認該應用程式是否可以連接到資料庫伺服器。

3.1. 驗證 MySQL 伺服器是否正在執行

導致此錯誤最直接的原因可能是 MySQL 伺服器實例未執行。顯然，如果服務未啟動，JDBC 驅動程式就無法連接到它。

在這種情況下，簡單的重啟即可解決問題：

# sudo service mysql restart

伺服器重啟後，應用程式應該能夠正常重新連接。但是，間歇性重啟也可能導致此問題，在這種情況下，可能需要進一步調試。

3.2 檢查 JDBC 連線 URL

初始 MySQL 連線的關鍵參數可能會導致通訊失敗。

讓我們分析一個典型的 MySQL JDBC 連線字串：

jdbc:mysql://localhost:3306/mydatabase

在進行故障排除時，我們應該驗證至少幾個參數的正確性：

• 主機名稱或 IP 位址
• 連接埠號碼（預設值：3306）
• 資料庫名稱
• 使用者名稱和密碼

具體來說，錯誤的連接埠或主機名稱可能會導致應用程式完全無法連接到伺服器。

3.3 測試主機名稱解析

與任何網路問題一樣，主機名稱和主機位址之間的區別至關重要。名稱解析失敗足以阻塞連線。這通常有以下幾個可能的原因：

• 作業系統配置錯誤
• hosts 檔案項目錯誤
• DNS 伺服器設定錯誤
• DNS 伺服器不知道主機
• DNS伺服器無回應

任何這些因素都可能導致 JDBC 驅動程式無法連接到伺服器。為了檢查問題，我們可以嘗試將localhost或MYSQL-1之類的名稱替換為明確的 IP 位址，例如127.0.0.1或192.168.6.66 。

如果使用明確的 IP 位址連線成功，但使用主機名稱連線失敗，則很可能是 DNS 或主機名稱解析問題導致的。相反，如果即使使用直接 IP 位址連線仍然失敗，則根本原因更有可能與網路、防火牆規則、連接埠錯誤或 MySQL 伺服器配置有關。讓我們逐一分析這些可能性。

4. MySQL 設定問題

如果能夠存取伺服器所在的實際硬件，但仍遇到問題，則可能是 MySQL 的網路連線配置不正確。為了診斷這個問題，我們通常會檢查 MySQL 設定檔（ my.cnf或my.ini ）中的選項和值。

4.1. 驗證bind-address設置

MySQL 的一個常見選項是bind-address 。

具體來說， bind-address的值決定了伺服器監聽的網路介面：

bind-address = 127.0.0.1

在這種情況下，我們只期望來自本地localhost連線。

另一方面，我們可以接受到任何位址或介面的連接：

bind-address = 0.0.0.0

檢查bind-address是否已正確設定為預期值對於診斷連接問題至關重要。

4.2. 停用skip-networking

某些 MySQL 安裝支援skip-networking設定選項，該選項會完全停用 TCP/IP 連線。

因此，如果該設定出現在設定檔中，我們應該將其註解掉：

# skip-networking

雖然這種情況很少見，但檢查這類極端情況只需花費少量時間，而且可以解決問題。因此，值得一試。

4.3 調整連線逾時設定

為防止資源浪費，MySQL 可能會關閉長時間處於閒置狀態的連線。

多種參數控制著這種行為：

• wait_timeout ：關閉空閒非互動連線前等待的最長時間
• interactive_timeout ：關閉空閒互動連線（例如mysql CLI）之前等待的最大時間
• connect_timeout ：等待客戶端完成初始連線握手的最長時間

如預期的那樣，增加這些值可以減少意外連線失敗：

wait_timeout = 28800

 interactive_timeout = 28800

在任何情況下，更改配置後，我們都應該重新啟動 MySQL 服務。

5. 網路和環境問題

即使 MySQL 配置正確，外部因素仍然可能阻止應用程式連接。

5.1. 防火牆和防毒軟體或代理限制

網路控制措施可能會阻止應用程式和 MySQL 伺服器之間的通訊。例如，防火牆規則、防毒軟體或代理程式都可能導致連線問題。

為了確保連線成功，我們可以使用ping或telnet等工具進行簡單檢查，並使用nmap進行連接埠測試。

無論網路配置如何，我們都應確保連接埠3306在整個網路中開放且可存取。當然，如果 MySQL 配置為監聽其他端口，我們應該針對該特定端口而不是3306驗證連接性。

5.2. IPv6 與 IPv4 的問題

某些環境會將名稱解析為 IPv6 位址，例如將localhost解析為::1而不是其對應的 IPv4 位址127.0.0.1 。但是，如果 Java 應用程式環境和 MySQL 伺服器使用的 IP 位址版本不同，則可能會出現連線失敗的情況。

常見解決方案：

1. 請使用127.0.0.1而不是localhost
2. 啟動 Java 時使用 JVM 選項-Djava.net.preferIPv4Stack=true

這將強制應用程式優先使用 IPv4 網路。

6. 應用層原因

應用程式的實作方式也會影響連線的建立和穩定性。

6.1 連接池中的過期連接

連線池中存在過期條目是導致 MySQL 連線問題的常見原因。當應用程式嘗試透過伺服器已關閉的連線執行查詢時，JDBC 驅動程式會報告通訊失敗。

通常情況下，解決方案是切換到現代連接池：

• HikariCP
• Apache DBCP
• C3PO

原因是這些實作會在將連線傳回給應用程式之前對其進行驗證。

在實際應用中，連接池可能需要明確配置來驗證或回收過期的連接。例如，HikariCP 使用了以下幾個設定：

• maxLifetime
• idleTimeout
• keepaliveTime

Apache DBCP 和 C3P0 支援驗證查詢和連線測試選項。具體細節超出本文討論範圍。

6.2 連接池耗盡

由於連線數限制，可能需要在嘗試建立新連線之前關閉舊連線。否則，MySQL 伺服器可能會拒絕連線嘗試。

尤其重要的是，確保 JDBC 資源正確關閉：

try (Connection conn = dataSource.getConnection()) {

 // execute queries

 }

連接池還可以限制和回收連接。

即使應用程式關閉了所有 JDBC 資源，資料庫伺服器仍可能拒絕新的連線。例如，MySQL 可能達到max_connections限製或遇到臨時過載情況。在這種情況下，應用程式可能會收到不同的異常，包括Too many connections之類的錯誤，而不是通用的CommunicationsException異常。

此外，配置的連接池大小至關重要。如果連線池允許的並發連線數超過 MySQL 允許的最大連線數，伺服器連線可能會被耗盡。因此，連接池大小和 MySQL 中的max_connections之間應該保持適當的平衡。

6.3 更新 JDBC 驅動程式

舊版的 MySQL Connector/J 驅動程式可能無法與新版本的資料庫可靠地搭配使用。

更新相依性通常可以解決相容性問題：

<dependency>

 <groupId>mysql</groupId>

 <artifactId>mysql-connector-java</artifactId>

 <version>8.0.33</version>

 </dependency>

對於 Connector/J 8.x ，Maven 工件也可能出現在較新的座標com.mysql:mysql-connector-j下，取決於專案設定和儲存庫元資料。

與其他電腦領域一樣，保持驅動程式更新可確保與 MySQL 協定相容並提高連線穩定性。

7. 總結

本文探討如何使用 MySQL 診斷和修復 Java 應用程式中的Communications link failure錯誤。

當 JDBC 驅動程式無法與資料庫伺服器通訊時，會發生此錯誤。常見原因包括伺服器停機、連線設定錯誤、MySQL 網路設定、防火牆限制、IPv6 解析問題、過期的連線池連線以及應用程式內的連線耗盡。

仔細驗證連接性、檢查 MySQL 配置、使用可靠的連接池、更新 JDBC 驅動程式以及檢查診斷日誌可以顯著減少依賴 MySQL 的 Java 應用程式的通訊故障。