針對適用於 MySQL 的 Azure 資料庫 - 彈性伺服器連線能力問題進行疑難排解
適用於：
適用於 MySQL 的 Azure 資料庫 - 單一伺服器適用於 MySQL 的 Azure 資料庫 - 彈性伺服器
重要
適用於 MySQL 的 Azure 資料庫單一伺服器位於淘汰路徑上。 強烈建議您升級至適用於 MySQL 的 Azure 資料庫彈性伺服器。 如需移轉至適用於 MySQL 的 Azure 資料庫彈性伺服器的詳細資訊，請參閱適用於 MySQL 的 Azure 資料庫單一伺服器會發生什麼事？
MySQL Community Edition 會在每個連線使用一個執行緒來管理連線。 因此，每個使用者連線都會在 mysqld 流程中取得專用的作業系統執行緒。
這種類型的連線處理方式會伴隨著潛在問題。 例如，若有大量使用者連線，則記憶體使用量會相當高，即使是閒置連線也不例外。 此外，在執行數千個使用者連線時，內部伺服器彼此競爭和環境切換的情況會較嚴重。
診斷常見的連線錯誤
適用於 MySQL 的 Azure 資料庫彈性伺服器的執行個體遇到連線問題時，請記得問題可能存在於涉及的這三個層級之中：用戶端裝置、網路，或者適用於 MySQL 的 Azure 資料庫彈性伺服器執行個體。
因此，每次診斷連線錯誤時，請務必將下列事項的所有細節納入考量：
- 用戶端，包括：
- 設定 (內部部署、Azure VM 等等，或 DBA 電腦)。
- 作業系統。
- 軟體和版本。
- 連接字串和任意包括的參數。
- 網路拓撲 (相同區域？相同 AZ？防火牆規則？路由)。
- 連線集區 (參數和組態)，如果正在使用的話。
請務必判斷資料庫連線問題是影響單一用戶端裝置或多個用戶端裝置。 如果錯誤只影響多個用戶端的其中一個，則可能是該用戶端的問題。 不過，如果所有用戶端都遇到相同的錯誤，則問題更有可能位於資料庫伺服器端，或兩者之間的網路功能。
請務必考慮工作負載超載的可能性，特別是當應用程式在非常短的時間內開啟大量連線時。 您可以使用「連線數總計」、「作用中的連線」和「中止的連線」之類的計量來調查此問題。
當您從用戶端裝置或應用程式建立連線時，在 mysql 中的首個重要呼叫為 getaddrinfo，其會從提供 IP 位址的端點來執行 DNS 轉譯。 若收到該位址的執行失敗，MySQL 會顯示錯誤訊息，例如「2005 錯誤 (HY000)：未知的 MySQL 伺服器主機‘mysql-example.mysql.database.azure.com’(11)」，以及結尾號碼 (11、110 等)。
用戶端錯誤 2005 代碼
下表顯示某些用戶端錯誤 2005 代碼的快速參考說明。
| 2005 錯誤代碼 | 注意事項 |
|---|---|
| (11)「EAI_SYSTEM - 系統錯誤」 | 用戶端上的 DNS 解析發生錯誤。 不是適用於 MySQL 的 Azure 資料庫彈性伺服器問題。 在用戶端上使用 dig/nslookup 進行疑難排解。 |
| (110) 「ETIMEDOUT - 連線逾時」 | 連線到用戶端 DNS 伺服器時發生逾時。 不是適用於 MySQL 的 Azure 資料庫彈性伺服器問題。 在用戶端上使用 dig/nslookup 進行疑難排解。 |
| (0)「名稱未知」 | DNS 無法解析指定的名稱。 檢查用戶端的輸入。 這很可能並非適用於 MySQL 的 Azure 資料庫彈性伺服器問題。 |
在 mysql 中的第二個呼叫為具備通訊端連線能力，而且在查看錯誤訊息時，例如「2003 錯誤 (HY000)：無法在‘mysql-example.mysql.database.azure.com’(111) 連線至適用於 MySQL 的 Azure 資料庫彈性伺服器」，結尾號碼 (99、110、111、113 等等)。
用戶端 2003 錯誤代碼
下表顯示某些用戶端錯誤 2003 代碼的快速參考說明。
| 2003 錯誤代碼 | 注意事項 |
|---|---|
| (99) 「EADDRNOTAVAIL - 無法指派要求的位址」 | 本錯誤並非由適用於 MySQL 的 Azure 資料庫彈性伺服器所造成，而是在用戶端造成。 |
| (110) 「ETIMEDOUT - 連線逾時」 | 連線到提供的 IP 位址出現逾時。 可能是安全性 (防火牆規則) 或網路功能 (路由) 問題。 通常，這並非適用於 MySQL 的 Azure 資料庫彈性伺服器的問題。 在用戶端裝置上使用 nc/telnet/TCPtraceroute 以進行疑難排解。 |
| (111)「ECONNREFUSED - 連線遭拒」 | 當封包到達目標伺服器時，伺服器拒絕連線。 這可能是嘗試連線到錯誤的伺服器或錯誤的連接埠。 這也可能與目標服務 (適用於 MySQL 的 Azure 資料庫彈性伺服器) 遭關閉、自容錯移轉復原，或經歷損毀復原，且尚未接受連線有關。 此問題可能生在用戶端或伺服器端。 在用戶端裝置上使用 nc/telnet/TCPtraceroute 以進行疑難排解。 |
| (113)「EHOSTUNREACH - 無法連線到主機」 | 用戶端裝置的路由表不包含通往資料庫伺服器所在網路的路徑。 檢查用戶端裝置的網路設定。 |
其他錯誤碼
下表顯示關於成功與資料庫伺服器建立網路連線後所發生問題的一些其他錯誤碼之快速參考說明。
| 錯誤碼 | 注意事項 |
|---|---|
| 錯誤 2013「失去對 MySQL 伺服器的連線」 | 連線已建立，但隨後失去。 如果嘗試連線的對象不是 MySQL (例如：使用 MySQL 用戶端連線連接埠 22 的 SSH)，就可能發生這種情況。 如果超級使用者終止工作階段，也可能會發生此情況。 如果資料庫的工作階段逾時，也可能會發生此情況。 或者，也可能是資料庫伺服器在建立連線後出現問題。 在用戶端連線存留期間內的任何時間都可能發生這種情況。 它可能表明資料庫發生嚴重問題。 |
| 錯誤 1040「太多連線」 | 已連線的資料庫用戶端數目已經達到設定的最大數目。 需要評估針對資料庫建立如此多連線的原因。 |
| 錯誤 1045「拒絕使用者存取」 | 用戶端提供了不正確的使用者名稱或密碼，因此資料庫拒絕存取。 |
| 錯誤 2006「MySQL 伺服器已消失」 | 與上表中的錯誤 2013「失去對 MySQL 伺服器的連線」類似。 |
| 錯誤 1317「查詢執行已中斷」 | 當主要使用者停止查詢而非連線時，用戶端會收到的錯誤。 |
| 1129 錯誤「主機‘1.2.3.4’由於許多連結錯誤而遭封鎖」 | 使用‘mysqladmin flush-hosts’解除封鎖 - 若該機器的其中一個用戶端多次嘗試使用錯誤的通訊協定連結至 MySQL，在單一電腦中的所有用戶端將遭到封鎖 (連線至 MySQL 連接埠為其中一個範例)。 如錯誤訊息所述，資料庫的管理使用者必須執行 FLUSH HOSTS; 才能清除問題。 |
注意
如需連線錯誤的詳細資訊，請參閱部落格文章 調查適用於 MySQL 的 Azure 資料庫彈性伺服器連線問題。
下一步
若想知道是否有人可解答您最重要的問題，或是要張貼或回答問題，請造訪 Stack Overflow。