本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
針對 Aurora MySQL 資料庫的連線問題進行疑難排解
確保應用程式與 RDS 資料庫執行個體之間的可靠連線,對於工作負載的順暢操作至關重要。不過,連線問題可能會因為各種因素而產生,例如網路組態、驗證問題或資源限制。本指南旨在提供全方位方法來針對 Aurora MySQL 的連線問題進行疑難排解。
內容
識別 Aurora MySQL 的資料庫連線問題
識別連線問題的特定類別有助於縮小潛在原因範圍,並引導疑難排解程序。每個類別可能需要不同的診斷和解決方法和技術。資料庫連線問題可廣泛分類為下列類別。
- 連線錯誤和例外狀況
-
連線錯誤和例外狀況可能因各種原因而發生,例如不正確的連線字串、驗證失敗、網路中斷或資料庫伺服器問題。原因可能包括設定錯誤的連線參數、無效的憑證、網路中斷或資料庫伺服器當機或重新啟動。設定錯誤的安全群組、虛擬私有雲端 (VPC) 設定、網路存取控制清單 (ACL) 以及與子網路相關聯的路由表也可能導致連線問題。
- 達到連線限制
-
當資料庫伺服器的並行連線數目超過允許的上限時,就會發生此問題。資料庫伺服器通常具有由叢集和執行個體參數群組中的參數 max_connections 定義的可設定連線上限。透過強加連線限制,資料庫伺服器可確保其有足夠的資源 (例如記憶體、CPU 和檔案控點) 可有效率地處理現有連線並提供可接受的效能。原因可能包括應用程式中的連線洩漏、連線集區效率低下,或連線請求意外突增。
- 連線逾時。
-
當用戶端應用程式無法在指定的逾時期間內與資料庫伺服器建立連線時,就會發生連線逾時。常見原因包括網路問題、伺服器過載、防火牆規則和設定錯誤的連線設定。
- 閒置連線逾時
-
資料庫伺服器可能會自動關閉長時間處於非作用中狀態的閒置連線,以節省資源。此逾時通常可使用
wait_timeout和interactive_timeout parameters來設定,且應根據應用程式的連線使用模式進行調整。原因可能包括讓連線長時間閒置的應用程式邏輯,或不當的連線管理。 - 現有連線的間歇中斷連線
-
此錯誤類別是指用戶端應用程式與資料庫之間已建立的連線,即使處於作用中狀態和使用中,仍會以不規律的間隔意外終止或中斷連線的情況。這些中斷連線會間歇性發生,這表示它們會以不規律的間隔發生,而不是一致的間隔。原因可包含下列項目:
-
資料庫伺服器問題,例如重新啟動或容錯移轉
-
不當的應用程式連線處理
-
負載平衡和代理問題
-
網路不穩定
-
連線路徑中涉及的第三方元件或中介軟體問題
-
查詢執行逾時
-
伺服器端或用戶端的資源限制
透過全面監控、記錄和分析來識別根本原因至關重要,同時實作適當的錯誤處理、連線集區和重試機制,有助於緩解這些間歇性中斷連線對應用程式功能和使用者體驗的影響。
-
收集 Aurora MySQL 連線問題的資料
收集與應用程式、資料庫、網路和基礎設施元件相關的完整資料,對於有效針對應用程式與 Aurora MySQL 資料庫之間的連線問題進行疑難排解至關重要。透過收集相關的日誌、組態和診斷資訊,您可以獲得寶貴的洞察,以協助識別連線問題的根本原因,並引導您進行適當的解決方案。
網路日誌和組態,例如安全群組規則、VPC 設定和路由表,對於識別可能使應用程式無法與資料庫建立成功連線的潛在網路相關瓶頸或組態錯誤至關重要。透過分析這些網路元件,您可以確保必要的連接埠已開啟、允許 IP 地址,以及正確設定路由組態。
- 時間戳記
-
發生連線問題時,請記錄確切的時間戳記。這有助於識別模式,或將問題與其他事件或活動建立關聯。
- 資料庫引擎日誌
-
除了一般資料庫日誌之外,請檢閱資料庫引擎日誌 (例如 MySQL 錯誤日誌和慢查詢日誌) 是否有任何相關資訊或可能與間歇性連線問題相關的錯誤。如需更多詳細資訊,請參閱 記錄 Aurora MySQL 資料庫。
- 用戶端應用程式日誌
-
從連線至資料庫的用戶端應用程式收集詳細日誌。應用程式日誌可從應用程式的角度提供連線嘗試、錯誤和任何相關資訊的可見性,這可能會顯示與連線字串、驗證憑證或應用程式層級連線處理相關的問題。
另一方面,資料庫日誌提供對資料庫端錯誤、慢速查詢或可能導致連線問題的事件的洞察。如需更多詳細資訊,請參閱 記錄 Aurora MySQL 資料庫。
- 用戶端環境變數
-
檢查用戶端的任何環境變數或組態設定是否可能影響資料庫連線,例如代理設定、SSL/TLS 設定或任何其他相關變數。
- 用戶端程式庫版本
-
確定用戶端使用用於資料庫連線的任何資料庫驅動程式、程式庫或架構的最新版本。過期版本可能會有已知問題或相容性問題。
- 用戶端網路擷取
-
使用 Wireshark 或
tcpdump等工具在發生連線問題期間,在用戶端執行網路擷取。這有助於識別用戶端上任何網路相關問題或異常。 - 用戶端網路拓撲
-
了解用戶端的網路拓撲,包括任何防火牆、負載平衡器或其他元件,例如 RDS Proxy 或 Proxy SQL,這些元件正在與資料庫進行連線,而不是用戶端直接進行連線。
- 用戶端作業系統設定
-
檢查可能影響網路連線的用戶端作業系統設定,例如防火牆規則、網路轉接器設定,以及任何其他相關設定。
- 連線集區組態
-
如果您在應用程式中使用連線集區機制,請檢閱組態設定並監控集區指標 (例如作用中連線、閒置連線和連線逾時),以確保集區正常運作。同時檢閱集區設定,例如集區大小上限、集區大小下限和連線驗證設定,以確保設定正確。
- 連接字串
-
連線字串通常包含主機名稱或端點、連接埠號碼、資料庫名稱和驗證憑證等參數。分析連線字串有助於識別可能導致連線問題的潛在錯誤組態或不正確的設定。例如,不正確的主機名稱或連接埠號碼可能會導致用戶端無法連線到資料庫執行個體,而無效的驗證憑證可能會導致驗證失敗和連線遭拒。此外,連線字串可能會顯示與連線集區、逾時或其他可能導致連線問題之連線特定設定相關的問題。提供用戶端應用程式使用的完整連線字串,有助於精確找出用戶端上的任何錯誤組態。
- 資料庫指標
-
在發生連線問題期間監控資料庫指標,例如 CPU 用量、記憶體用量和磁碟 I/O。這些項目可協助識別資料庫執行個體是否遇到資源爭用或效能問題。
- DB engine version (資料庫引擎版本)
-
請注意 Aurora MySQL 資料庫引擎版本。AWS 會定期發行更新,以解決已知問題、安全漏洞並引入效能增強功能。因此,強烈建議您升級至最新的可用版本,因為這些更新通常包含與連線能力、效能和穩定性相關的錯誤修正和改進。提供資料庫版本資訊以及其他收集的詳細資訊,可協助 支援 有效診斷和解決連線問題。
- 網路指標
-
在發生連線問題期間收集網路指標,例如延遲、封包遺失和輸送量。
ping、traceroute和網路監控工具等工具可協助收集此資料。 - 來源和用戶端詳細資訊
-
判斷正在啟動資料庫連線的應用程式伺服器、負載平衡器或任何其他元件的 IP 地址。這可以是單一 IP 地址或 IP 地址範圍 (CIDR 表示法)。如果來源是 Amazon EC2 執行個體,也有助於檢閱與執行個體相關聯的執行個體類型、可用區域、子網路 ID 和安全群組,以及私有 IP 地址和公有 IP 地址等網路介面詳細資訊。
透過徹底分析收集的資料,您可以識別錯誤組態、資源限制、網路中斷或其他導致間歇性或持久性連線問題的基礎問題。此資訊可讓您採取有針對性的動作,例如調整組態、解決網路問題,或解決應用程式層級連線處理。
監控 Aurora MySQL 的資料庫連線
若要監控連線問題並進行疑難排解,您可以使用下列指標和功能。
- CloudWatch 指標
-
-
CPUUtilization– 資料庫執行個體上的高 CPU 用量可能會導致查詢執行緩慢,進而導致連線逾時或遭拒。 -
DatabaseConnections– 監控資料庫執行個體的作用中連線數目。接近已設定最大值的高連線數量,可能表示潛在的連線問題或連線集區耗盡。 -
FreeableMemory– 由於資源限制,可用記憶體不足可能會導致效能問題和連線問題。 -
NetworkReceiveThroughput和NetworkTransmitThroughput– 網路輸送量異常峰值或下降可能表示連線問題或網路瓶頸。
-
- 績效詳情指標
-
若要使用 Performance Insights 針對 Aurora MySQL 中的連線問題進行疑難排解,請分析資料庫指標,如下所示:
-
Aborted_clients
-
Aborted_connects
-
連線
-
max_connections
-
Threads_connected
-
Threads_created
-
Threads_running
這些指標可協助您識別連線瓶頸、偵測網路或驗證問題、最佳化連線集區,並確保有效的執行緒管理。如需更多詳細資訊,請參閱 Aurora MySQL 的績效詳情計數器。
-
- Performance Insights 功能
-
-
資料庫負載 – 視覺化一段時間內的資料庫負載,並將其與連線問題或效能降級建立關聯。
-
SQL 統計資料 – 分析 SQL 統計資料,以識別可能造成連線問題的低效率查詢或資料庫操作。
-
熱門查詢 – 識別和分析資源最密集的查詢,這有助於識別可能導致連線問題的潛在效能瓶頸或長時間執行的查詢。
-
透過監控這些指標並利用 Performance Insights,您可以了解資料庫執行個體的效能、資源用量,以及可能導致連線問題的潛在瓶頸。例如:
-
接近上限的高
DatabaseConnections可能表示連線集區耗盡或不當的連線處理,導致連線問題。 -
高
CPUUtilization或低FreeableMemory可能表示資源限制,這可能會導致查詢執行緩慢和連線逾時或遭拒。 -
分析熱門查詢和 SQL 統計資料有助於識別可能導致連線問題的效率低下或資源密集型查詢。
此外,監控 CloudWatch Logs 和設定警示可協助您在連線問題升級之前主動識別和回應。
請務必注意,雖然這些指標和工具可以提供寶貴的洞察,但應該與其他疑難排解步驟搭配使用。透過檢閱網路組態、安全群組規則和應用程式層級連線處理,您可以全面診斷和解決 Aurora MySQL 資料庫執行個體的連線問題。
Aurora MySQL 的其他監控
- CloudWatch 指標
-
-
AbortedClients– 追蹤未正確關閉的用戶端連線數目。 -
AuroraSlowConnectionHandleCount– 追蹤緩慢連線處理操作的數量,指出潛在的連線問題或效能瓶頸。 -
AuroraSlowHandshakeCount– 測量緩慢交握操作的數量,這也可能是連線問題的指標。 -
ConnectionAttempts– 測量對 Aurora MySQL 資料庫執行個體進行的連線嘗試次數。
-
- 全域狀態變數
-
Aurora_external_connection_count– 顯示資料庫執行個體的資料庫連線數目,排除用於資料庫運作狀態檢查的 RDS 服務連線。
透過監控這些指標和全域狀態變數,您可以了解可能導致 Amazon Aurora MySQL 執行個體連線問題的連線模式、錯誤和潛在瓶頸。
例如,大量 AbortedClients 或 AuroraSlowConnectionHandleCount 可能表示連線問題。
此外,設定 CloudWatch 警示和通知可協助您在連線問題升級並影響應用程式效能之前,主動識別和回應連線問題。
Aurora MySQL 的連線錯誤代碼
以下是 Aurora MySQL 資料庫的一些常見連線錯誤,以及其錯誤代碼和說明。
- 錯誤代碼 1040:太多連線
-
當用戶端嘗試建立的連線數量超過資料庫伺服器允許的上限時,就會發生此錯誤。可能的子句包括:
-
連線集區錯誤組態 – 如果使用連線集區機制,請確定集區大小上限未設定得太高,且連線已正確釋放回集區。
-
資料庫執行個體組態 – 驗證資料庫執行個體允許的連線設定上限,並視需要設定
max_connections參數進行調整。 -
高並行 – 如果多個用戶端或應用程式同時連線到資料庫,可能會達到允許的連線上限。
-
- 錯誤代碼 1045:拒絕使用者 '...'@'...' 的存取 (使用密碼:是/否)
-
此錯誤表示嘗試連線至資料庫時發生驗證失敗。可能的子句包括:
-
驗證外掛程式相容性 – 檢查用戶端使用的驗證外掛程式是否與資料庫伺服器的驗證機制相容。
-
不正確的使用者名稱和密碼 – 確認在連線字串或驗證機制中使用正確的使用者名稱和密碼。
-
使用者許可 – 確定使用者具有從指定主機或網路連線至資料庫執行個體的必要許可。
-
- 錯誤代碼 1049:不明資料庫 '...'
-
此錯誤表示用戶端嘗試連線到伺服器上不存在的資料庫。可能的子句包括:
-
未建立資料庫 – 確定已在資料庫伺服器上建立指定的資料庫。
-
資料庫名稱不正確 – 再次檢查在連線字串或查詢中使用的資料庫名稱是否正確。
-
使用者許可 – 確認使用者具有存取指定資料庫的必要許可。
-
- 錯誤代碼 1153:擁有大於 'max_allowed_packet' 位元組的封包
-
當用戶端嘗試傳送或接收的資料超過資料庫伺服器允許的封包大小上限時,就會發生此錯誤。可能的子句包括:
-
大型查詢或結果集 – 如果執行涉及大量資料的查詢,可能會超過封包大小限制。
-
設定錯誤的封包大小設定 – 檢查資料庫伺服器上的
max_allowed_packet設定,並視需要進行調整。 -
網路組態問題 – 確定網路組態 (例如 MTU 大小) 允許所需的封包大小。
-
- 錯誤代碼 1226:使用者 '...' 已超過 'max_user_connections' 資源 (目前值:...)
-
此錯誤表示使用者已超過資料庫伺服器允許的並行連線數目上限。可能的原因包括下列項目:
-
連線集區錯誤組態 – 如果使用連線集區機制,請確定集區大小上限針對使用者的連線限制未設定得太高。
-
資料庫執行個體組態 – 驗證資料庫執行個體的
max_user_connections設定,並視需要進行調整。 -
高並行 – 如果多個用戶端或應用程式同時使用相同使用者連線到資料庫,可能會達到使用者特定連線限制。
-
- 錯誤代碼 2003:無法在 '...' 上連線至 MySQL 伺服器 (10061)
-
此錯誤通常發生在用戶端無法與資料庫伺服器建立 TCP/IP 連線時。其可能由各種問題造成,例如下列項目:
-
資料庫執行個體狀態 – 確定資料庫執行個體處於
available狀態,而且不會進行任何維護或備份操作。 -
防火牆規則 – 檢查是否有任何防火牆 (作業系統、網路或安全群組) 封鎖指定連接埠上的連線 (針對 MySQL 通常是 3306)。
-
不正確的主機名稱或端點 – 請確定在連線字串中使用的主機名稱或端點正確且符合資料庫執行個體。
-
網路連線問題 – 確認用戶端機器可以透過網路連線資料庫執行個體。檢查是否有任何網路中斷、路由問題,或 VPC 或子網路錯誤組態。
-
- 錯誤代碼 2005:不明 MySQL 伺服器主機 '...' (11001)
-
當用戶端無法將資料庫伺服器的主機名稱或端點解析為 IP 地址時,就會發生此錯誤。可能的子句包括:
-
DNS 解析問題 – 確認用戶端機器可以使用 DNS 正確解析主機名稱。檢查 DNS 設定、DNS 快取,並嘗試使用 IP 地址而非主機名稱。
-
不正確的主機名稱或端點 – 再次檢查在連線字串中使用的主機名稱或端點是否正確。
-
網路組態問題 – 確定用戶端的網路組態 (例如 VPC、子網路和路由表) 允許 DNS 解析和連線至資料庫執行個體。
-
- 錯誤代碼 2026:SSL 連線錯誤
-
當連線嘗試期間發生 SSL/TLS 組態或憑證驗證問題時,就會發生此錯誤。可能的子句包括:
-
憑證過期 – 檢查伺服器使用的 SSL/TLS 憑證是否已過期且需要續約。
-
憑證驗證問題 – 驗證用戶端是否能夠正確驗證伺服器的 SSL/TLS 憑證,以及憑證是否可信任。
-
網路組態問題 – 確定網路組態允許 SSL/TLS 連線,而且不會封鎖或干擾 SSL/TLS 交握程序。
-
SSL/TLS 組態不符 – 確定用戶端和伺服器上的 SSL/TLS 設定 (例如,密碼套件和通訊協定版本) 相容。
-
透過了解每個錯誤代碼的詳細說明和潛在原因,您可以在使用 Aurora MySQL 資料庫時更好地疑難排解和解決連線問題。
Aurora MySQL 的參數調校建議
- 連線數上限
-
調整這些參數有助於防止因達到允許的最大連線限制而導致的連線問題。請確定根據應用程式的並行要求和資源限制,適當地設定這些值。
-
max_connections– 此參數指定允許的資料庫執行個體並行連線數目上限。 -
max_user_connections– 您可以在使用者建立和修改期間指定此參數,並設定針對特定使用者帳戶允許的並行連線數目上限。
-
- 網路緩衝區大小
-
增加這些值可以改善網路效能,尤其是涉及大型資料傳輸或結果集的工作負載。不過請小心謹慎,因為較大的緩衝區大小可能會耗用更多記憶體。
-
net_buffer_length– 此參數會設定用戶端連線和結果緩衝區的初始大小,平衡記憶體用量與查詢效能。 -
max_allowed_packet– 此參數指定資料庫執行個體可傳送或接收的單一網路封包大小上限。
-
- 網路壓縮 (用戶端)
-
啟用網路壓縮可以減少網路頻寬用量,但可能會增加用戶端和伺服器端的 CPU 額外負荷。
-
compress– 此參數會啟用或停用用戶端/伺服器通訊的網路壓縮。 -
compress_protocol– 此參數指定用於網路通訊的壓縮通訊協定。
-
- 網路效能調校
-
調整這些逾時有助於管理閒置連線並防止資源耗盡,但請小心謹慎,因為低值可能會導致連線提早終止。
-
interactive_timeout– 此參數指定伺服器在互動式連線上關閉活動之前等待的秒數。 -
wait_timeout– 此參數決定伺服器在非互動式連線上關閉活動之前等待的秒數。
-
- 網路逾時設定
-
調整這些逾時有助於解決與緩慢或無回應連線相關的問題。但請小心不要將其設得太低,因為這可能會導致連線過早失敗。
-
net_read_timeout– 此參數指定在結束讀取操作之前等待來自連線之更多資料的秒數。 -
net_write_timeout– 此參數決定在結束寫入操作之前等待區塊寫入連線的秒數。
-
針對 Aurora MySQL 資料庫連線問題進行疑難排解的範例
下列範例示範如何識別 Aurora MySQL 的資料庫連線問題並進行疑難排解。
範例 1:針對失敗的連線嘗試進行疑難排解
連線嘗試可能會因為多種原因而失敗,包括驗證失敗、SSL/TLS 交握失敗、達到 max_connections 限制,以及資料庫執行個體的資源限制。
您可以從 Performance Insights 或使用下列命令來追蹤失敗連線的數量。
mysql> show global status like 'aborted_connects'; +------------------+-------+ | Variable_name | Value | +------------------+-------+ | Aborted_connects | 7 | +------------------+-------+ 1 row in set (0.00 sec)
如果 Aborted_connects 的數量隨時間增加,則應用程式可能會有間歇性連線問題。
您可以使用 Aurora 進階稽核來記錄與用戶端連線的連線和中斷連線。您可以在資料庫叢集參數群組中設定下列參數來執行此操作:
-
server_audit_logging=1 -
server_audit_events=CONNECT
以下是失敗登入之稽核日誌的擷取。
1728498527380921,auora-mysql-node1,user_1,172.31.49.222,147189,0,FAILED_CONNECT,,,1045 1728498527380940,auora-mysql-node1,user_1,172.31.49.222,147189,0,DISCONNECT,,,0
其中:
-
1728498527380921– 失敗登入發生時的 epoch 時間戳記 -
aurora-mysql-node1– 連線失敗之 Aurora MySQL 叢集節點的執行個體識別符 -
user_1– 登入失敗的資料庫使用者名稱 -
172.31.49.222– 建立連線之用戶端的私有 IP 地址 -
147189– 失敗登入的連線 ID -
FAILED_CONNECT– 表示連線失敗。 -
1045– 傳回碼。非零值表示錯誤。在此情況下,1045對應至存取遭拒。
如需詳細資訊,請參閱 MySQL 文件中的伺服器錯誤代碼
您也可以檢查 Aurora MySQL 錯誤日誌是否有任何相關的錯誤訊息,例如:
2024-10-09T19:26:59.310443Z 220 [Note] [MY-010926] [Server] Access denied for user 'user_1'@'172.31.49.222' (using password: YES) (sql_authentication.cc:1502)
範例 2:針對異常用戶端中斷連線進行疑難排解
您可以從 Performance Insights 或使用下列命令來追蹤異常用戶端中斷連線的數量。
mysql> show global status like 'aborted_clients'; +-----------------+-------+ | Variable_name | Value | +-----------------+-------+ | Aborted_clients | 9 | +-----------------+-------+ 1 row in set (0.01 sec)
如果 Aborted_clients 的數量隨著時間增加,則應用程式無法正確關閉與資料庫的連線。如果連線未正確關閉,可能會導致資源洩漏和潛在的效能問題。不必要地讓連線保持開啟可能會耗用系統資源,例如記憶體和檔案描述項,最終可能導致應用程式或伺服器變得無回應或重新啟動。
您可以使用下列查詢來識別未正確關閉連線的帳戶。它會擷取使用者帳戶名稱、使用者連線的主機、未關閉的連線數,以及未關閉的連線百分比。
SELECT ess.user, ess.host, (a.total_connections - a.current_connections) - ess.count_star AS not_closed, (((a.total_connections - a.current_connections) - ess.count_star) * 100) / (a.total_connections - a.current_connections) AS pct_not_closed FROM performance_schema.events_statements_summary_by_account_by_event_name AS ess JOIN performance_schema.accounts AS a ON (ess.user = a.user AND ess.host = a.host) WHERE ess.event_name = 'statement/com/quit' AND (a.total_connections - a.current_connections) > ess.count_star; +----------+---------------+------------+----------------+ | user | host | not_closed | pct_not_closed | +----------+---------------+------------+----------------+ | user1 | 172.31.49.222 | 1 | 33.3333 | | user1 | 172.31.93.250 | 1024 | 12.1021 | | user2 | 172.31.93.250 | 10 | 12.8551 | +----------+---------------+------------+----------------+ 3 rows in set (0.00 sec)
識別未關閉連線的使用者帳戶和主機之後,您可以繼續檢查未正常關閉連線的程式碼。
例如,使用 Python 中的 MySQL 連接器,使用連線物件的 close() 方法來關閉連線。以下是建立資料庫連線、執行查詢及關閉連線的範例函數:
import mysql.connector def execute_query(query): # Establish a connection to the database connection = mysql.connector.connect( host="your_host", user="your_username", password="your_password", database="your_database" ) try: # Create a cursor object cursor = connection.cursor() # Execute the query cursor.execute(query) # Fetch and process the results results = cursor.fetchall() for row in results: print(row) finally: # Close the cursor and connection cursor.close() connection.close()
在此範例中,會在 finally 區塊中呼叫 connection.close() 方法,以確保連線已關閉,無論是否發生例外狀況。