本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 管理連線
<a name="manage-connections"></a>

隨著應用程式需求的成長，前端流量也會增加。在一般案例中，您可以在應用程式層設定自動擴展來處理此類爆量的傳入流量。因此，應用程式層開始自動擴展，並新增更多應用程式伺服器 (執行個體) 來滿足流量的增加。由於所有應用程式伺服器都已預先設定資料庫連線集區設定，因此資料庫的傳入連線數量與新部署的執行個體成比例成長。

例如，20 個應用程式伺服器設定有 200 個資料庫連線，每個應用程式伺服器將總共開啟 4,000 個資料庫連線。如果應用程式集區縱向擴展至 200 個執行個體 (例如，在尖峰時間)，總連線數將達到 40,000 個。在典型工作負載下，大多數連線可能處於閒置狀態。但是，連線的激增可能會限制您的 Amazon Aurora MySQL 相容版資料庫的擴展能力。這是因為即使閒置連線也會耗用記憶體和其他伺服器資源，例如檔案描述元。Aurora MySQL 相容版通常使用比 MySQL 社群版更少的記憶體來維護相同數量的連線。但是，閒置連線的記憶體用量仍然不是零。

## 組態變數
<a name="config-variables"></a>

您可以使用以下兩個主要伺服器組態變數來控制資料庫允許的傳入連線數：`max_connections` 和 `max_connect_errors`。

**組態變數 max\_connections**

組態變數 `max_connections` 限制每個 MySQL 執行個體的資料庫連線數。最佳實務是將其設定為稍高於您預期在每個資料庫執行個體上開啟的連線數上限。

如果您也啟用 `performance_schema`，請格外小心 `max_connections` 設定。效能結構描述記憶體結構根據伺服器組態變數自動調整大小，包括 `max_connections`。您設定的變數越高，效能結構描述使用的記憶體就越多。在極端情況下，這可能會導致較小執行個體類型出現記憶體不足問題。請注意，啟用 Performance Insights 將自動啟用效能結構描述。

**組態變數 max\_connect\_errors**

組態變數 `max_connect_errors` 決定所指定用戶端主機允許的連續中斷的連線請求數量。如果用戶端主機超過指定的連續失敗連線嘗試次數，伺服器會封鎖它。該用戶端的進一步連線嘗試會產生錯誤。

`Host 'host_name' is blocked because of many connection errors. Unblock with 'mysqladmin flush-hosts'`

如果您遇到「主機遭到封鎖」錯誤，請避免增加`max_connect_errors`變數的值。相反，請調查 `aborted_connects` 狀態變數和 `host_cach` 資料表中的伺服器診斷計數器。使用收集的資訊來識別並修正遇到連線問題的用戶端。另請注意，如果 `skip_name_resolve` 設定為 `1` (預設)，則此參數無效。

如需有關下列項目的詳細資訊，請參閱 MySQL 參考手冊： 有關以下內容的詳細信息，請參閱《MySQL 參考手冊》：
+ [Max\_connect\_errors 變數](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_max_connect_errors)
+ [「主機已封鎖」錯誤](https://dev.mysql.com/doc/refman/8.0/en/host-cache.html#blocked-host)
+ [Aborted\_connects 狀態變數](https://dev.mysql.com/doc/refman/8.0/en/server-status-variables.html#statvar_Aborted_connects)
+ [Host\_cache 資料表](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-host-cache-table.html)

## 實作連線集區
<a name="connection-pooling"></a>

擴展事件可能會新增更多應用程式伺服器，這反過來又可能導致資料庫伺服器超過完整載入的作用中連線數。在應用程式伺服器與資料庫之間新增連線集區或代理層就像漏斗一樣，減少了資料庫上的連線總數。代理的主要目的是透過多工方式重複使用資料庫連線。

一方面，代理透過控制的連線數連接至資料庫。另一方面，代理接受應用程式連線。它還提供其他功能，例如查詢快取、連線緩衝、查詢重寫和路由以及負載平衡。連線集區層需要設定為保持資料庫的連線數上限低於完整載入數。[Amazon RDS Proxy](https://aws.amazon.com/rds/proxy/) 是您可以為此用途實作的全受管代理。Amazon RDS Proxy 不需要對大多數應用程式進行任何程式碼變更，並且您不需要管理任何額外基礎設施來實作解決方案。

您也可以探索下列可與 Aurora MySQL 相容搭配使用的第三方代理：
+ [ProxySQL](https://proxysql.com/)
+ [MariaDB MaxScale](https://mariadb.com/kb/en/maxscale/)
+ [ScaleARC](http://www.scalearc.com/)
+ [Heimdall Data](https://aws.amazon.com/blogs/apn/using-the-heimdall-proxy-to-split-reads-and-writes-for-amazon-aurora-and-amazon-rds/)

**避免連線風暴**

考慮在資料庫過載或複本落後於主節點太遠的情況下連線集區的行為方式。設定代理伺服器或連線集區時，確保不會因資料庫回應緩慢 (由基礎硬體或儲存問題或資料庫資源限制造成) 而重設整個連線集區。

突然啟動數百個連線會產生*連線風暴*，因為大量對資料庫的新連線請求都同時起始。風暴是資源密集型。在 MySQL 中建立新的資料庫連線是一項昂貴的操作，因為後端會交換多個網路封包以進行初始交握、產生新程序、配置記憶體、處理驗證等。如果在短時間內收到大量請求，資料庫可能沒有回應。

MySQL 有一種機制可防止連線請求中出現此類激增。`back_log` 變數可以設定為在 MySQL 暫時停止回答新請求之前短時間內可以堆疊的請求數。此值由連線處理執行緒強制執行，此執行緒本身可能會被連線風暴淹沒。如需詳細資訊，請參閱 [MySQL Reference Manual](https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_back_log)。

如果您的連線設定為在資料庫速度緩慢時重設，您將一次又一次地初始化循環。同樣，如果您預期一天中的某些時間 (例如，股市開盤時) 資料庫流量會突然增加，請預熱您的連線集區，以便您不會嘗試在高流量負載開始的同時開啟許多連線。