本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
針對 Aurora MySQL 資料庫的連線問題進行故障診斷
確保應用程式與RDS資料庫執行個體之間的可靠連線對於工作負載的順暢操作至關重要。不過,連線問題可能因為各種因素而產生,例如網路組態、身分驗證問題或資源限制。本指南旨在提供全方位方法來疑難排解 Aurora MySQL 的連線問題。
內容
識別 Aurora MySQL 的資料庫連線問題
識別連線問題的特定類別有助於縮小潛在原因範圍,並引導疑難排解程序。每個類別可能需要不同的診斷和解決方法和技術。資料庫連線問題可大致分類為下列類別。
- 連線錯誤和例外狀況
-
連線錯誤和例外狀況可能因各種原因而發生,例如不正確的連線字串、身分驗證失敗、網路中斷或資料庫伺服器問題。原因可能包括設定錯誤的連線參數、無效的登入資料、網路中斷或資料庫伺服器當機或重新啟動。設定錯誤的安全群組、虛擬私有雲端 (VPC) 設定、網路存取控制清單 (ACLs) 以及與子網路相關聯的路由表,也可能導致連線問題。
- 達到連線限制
-
當資料庫伺服器的並行連線數量超過允許的上限時,就會發生此問題。資料庫伺服器通常具有由叢集和執行個體參數群組中的 參數 max_connections 定義的可設定連線上限。透過設定連線限制,資料庫伺服器可確保其有足夠的資源 (例如記憶體、 CPU和 檔案控點) 可有效率地處理現有連線並提供可接受的效能。原因可能包括應用程式中的連線洩漏、連線集區效率低落,或連線請求意外激增。
- 連線逾時
-
當用戶端應用程式無法在指定的逾時期間內與資料庫伺服器建立連線時,就會發生連線逾時。常見原因包括網路問題、伺服器過載、防火牆規則和設定錯誤的連線設定。
- 閒置連線逾時
-
資料庫伺服器可能會自動關閉長時間保持非作用中的閒置連線,以節省資源。此逾時通常可使用
wait_timeout
和 設定interactive_timeout parameters
,且應根據應用程式的連線用量模式進行調整。原因可能包括讓連線長時間閒置的應用程式邏輯,或不當的連線管理。 - 現有連線的間歇中斷連線
-
此錯誤類別是指用戶端應用程式與資料庫之間建立的連線,即使處於作用中和使用中狀態,仍以不規律的間隔發生意外終止或中斷連線的情況。這些中斷連接會間歇發生,這表示它們會以不規律的間隔發生,而不是一致。原因可能包括下列項目:
-
資料庫伺服器問題,例如重新啟動或容錯移轉
-
不當的應用程式連線處理
-
負載平衡和代理問題
-
網路不穩定
-
連線路徑中涉及的第三方元件或中介軟體問題
-
查詢執行逾時
-
伺服器或用戶端的資源限制條件
透過全面監控、記錄和分析來識別根本原因至關重要,同時實作適當的錯誤處理、連線集區和重試機制,有助於減輕這些間歇性中斷連線對應用程式功能和使用者體驗的影響。
-
收集 Aurora MySQL 連線問題的資料
收集與應用程式、資料庫、網路和基礎設施元件相關的完整資料,對於有效疑難排解應用程式與 Aurora MySQL 資料庫之間的連線問題至關重要。透過收集相關日誌、組態和診斷資訊,您可以獲得寶貴的洞見,以協助識別連線問題的根本原因,並引導您進行適當的解決方案。
網路日誌和組態,例如安全群組規則、VPC設定和路由表,對於識別可能使應用程式無法與資料庫建立成功連線的潛在網路相關瓶頸或錯誤組態至關重要。透過分析這些網路元件,您可以確保必要的連接埠已開啟、允許 IP 地址,以及正確設定路由組態。
- 時間戳記
-
發生連線問題時,請記錄確切的時間戳記。這有助於識別模式,或將問題與其他事件或活動建立關聯。
- 資料庫引擎日誌
-
除了一般資料庫日誌之外,請檢閱資料庫引擎日誌 (例如,我的SQL錯誤日誌和慢查詢日誌) 是否有任何相關資訊或可能與間歇性連線問題相關的錯誤。如需詳細資訊,請參閱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
– 網路輸送量異常峰值或下降可能表示連線問題或網路瓶頸。
-
- 績效詳情指標
-
若要使用績效詳情對 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 日誌和設定警示可協助您在連線問題升級之前主動識別和回應。
請務必注意,雖然這些指標和工具可以提供寶貴的洞見,但應該與其他故障診斷步驟搭配使用。透過檢閱網路組態、安全群組規則和應用程式層級連線處理,您可以全面診斷並解決 Aurora MySQL 資料庫執行個體的連線問題。
Aurora My 的其他監控SQL
- 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:拒絕使用者 '...'@'...' 的存取 (使用密碼:YES/NO)
-
此錯誤表示嘗試連線至資料庫時發生身分驗證失敗。可能的子句包括:
-
身分驗證外掛程式相容性 – 檢查用戶端使用的身分驗證外掛程式是否與資料庫伺服器的身分驗證機制相容。
-
不正確的使用者名稱或密碼 – 確認連線字串或身分驗證機制中使用的使用者名稱和密碼正確無誤。
-
使用者許可 – 確定使用者具有從指定的主機或網路連線至資料庫執行個體的必要許可。
-
- 錯誤碼 1049:不明資料庫 '...'
-
此錯誤表示用戶端正在嘗試連線到伺服器上不存在的資料庫。可能的子句包括:
-
未建立資料庫 - 確定指定的資料庫已在資料庫伺服器上建立。
-
不正確的資料庫名稱 – 再次檢查連線字串或查詢中使用的資料庫名稱是否正確。
-
使用者許可 – 確認使用者具有存取指定資料庫的必要許可。
-
- 錯誤碼 1153:擁有大於 'max_allowed_packet' 位元組的封包
-
當用戶端嘗試傳送或接收的資料超過資料庫伺服器允許的封包大小上限時,就會發生此錯誤。可能的子句包括:
-
大型查詢或結果集 – 如果執行涉及大量資料的查詢,可能會超過封包大小限制。
-
設定錯誤的封包大小設定 – 檢查資料庫伺服器上
max_allowed_packet
的設定,並視需要調整。 -
網路組態問題 – 確定網路組態 (例如,MTU大小) 允許所需的封包大小。
-
- 錯誤碼 1226:使用者 '...' 已超過 'max_user_connections' 資源 (目前值:...)
-
此錯誤表示使用者已超過資料庫伺服器允許的並行連線數量上限。可能的原因包括:
-
連線集區設定錯誤 – 如果使用連線集區機制,請確保最大集區大小不會針對使用者的連線限制設定過高。
-
資料庫執行個體組態 – 驗證資料庫執行個體
max_user_connections
的設定,並視需要調整。 -
高並行 – 如果多個用戶端或應用程式同時使用相同的使用者同時連線到資料庫,可能會達到使用者特定的連線限制。
-
- 錯誤碼 2003:無法連線至 '...' 上的我的SQL伺服器 (10061)
-
當用戶端無法與資料庫伺服器建立 TCP/IP 連線時,通常會發生此錯誤。它可能由各種問題造成,例如:
-
資料庫執行個體狀態 – 確定資料庫執行個體處於
available
狀態,且不會進行任何維護或備份操作。 -
防火牆規則 – 檢查是否有任何防火牆 (作業系統、網路或安全群組) 封鎖指定連接埠上的連線 (通常為 3306 for MySQL)。
-
不正確的主機名稱或端點 – 請確定連線字串中使用的主機名稱或端點正確且符合資料庫執行個體。
-
網路連線問題 – 確認用戶端機器可以透過網路到達資料庫執行個體。檢查是否有任何網路中斷、路由問題或VPC子網路設定錯誤。
-
- 錯誤代碼 2005:不明的我的SQL伺服器主機 '...' (11001)
-
當用戶端無法將資料庫伺服器的主機名稱或端點解析為 IP 地址時,會發生此錯誤。可能的子句包括:
-
DNS 解決方案問題 – 確認用戶端機器可以使用 正確解析主機名稱DNS。檢查DNS設定、DNS快取,並嘗試使用 IP 地址而非主機名稱。
-
不正確的主機名稱或端點 – 再次檢查連線字串中使用的主機名稱或端點的準確性。
-
網路組態問題 – 確定用戶端的網路組態 (例如 VPC、子網路和路由表) 允許DNS解析和連線至資料庫執行個體。
-
- 錯誤碼 2026:SSL連線錯誤
-
當 SSL/TLS 組態或憑證驗證在連線嘗試期間發生問題時,就會發生此錯誤。可能的子句包括:
-
憑證過期 – 檢查伺服器使用的 SSL/TLS 憑證是否已過期,且需要續約。
-
憑證驗證問題 – 確認用戶端能夠正確驗證伺服器的 SSL/TLS 憑證,以及憑證是否可信任。
-
網路組態問題 – 確定網路組態允許SSL/TLS connections and doesn't block or interfere with the SSL/TLS交握程序。
-
SSL/TLS configuration mismatch – Make sure that the 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:對異常用戶端中斷連線進行故障診斷
您可以追蹤異常用戶端從績效詳情中斷連線的數量,或使用下列命令。
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()
方法,以確保連線已關閉,無論是否發生例外狀況。