本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
組態準則
本節說明 RDS Proxy 中可用的設定，並提供在整個應用程式堆疊中調整組態的最佳實務。這些是將 RDS Proxy 與 Amazon RDS 和 Amazon Aurora 搭配使用的合併準則。適用時，會呼叫 RDS 特定和 Aurora 特定備註。
除非另有說明，否則術語「資料庫」或「目標」是指 Aurora 叢集、Amazon RDS 多可用區域資料庫叢集或 Amazon RDS 執行個體。
RDS Proxy 的設定
MaxConnectionsPercent
| 最小值 | 最大值 | 預設值 |
|---|---|---|
| 小於 (1， MaxIdleConnectionsPercent) | 100 | 100 |
如需詳細資訊，請參閱MaxConnectionsPercent。
此設定會限制 RDS Proxy 可與目標資料庫建立的連線數，以資料庫允許的最大連線數百分比表示。代理會視需要開啟後端連線，因此任何指定時間的實際連線數可能低於設定的最大值。
由於 MaxConnectionsPercent設定是資料庫連線限制的百分比，代理的連線集區大小會自動遵循資料庫組態。這表示您不需要在每次調整資料庫執行個體大小或進行組態變更時重新設定代理。這也表示您需要注意資料庫設定可能變更的案例，無論是隱含還是明確：
-
如果您未在資料庫的參數群組中明確設定連線限制 （例如
max_connections參數），Amazon RDS 和 Aurora 會根據資料庫執行個體類別自動計算連線限制。因此，當您擴展資料庫執行個體時，隱含連線限制可能會變更，進而影響代理中的最大集區大小。如需詳細資訊，請參閱《Amazon RDS 使用者指南》中的資料庫連線數上限、Aurora MySQL 資料庫執行個體連線數上限，以及《Amazon Aurora 使用者指南》中的 Aurora PostgreSQL 資料庫執行個體連線數上限。 -
Aurora Serverless v2 資料庫執行個體會根據資料庫的最大 ACU 組態來決定其連線限制。如需詳細資訊，請參閱《Amazon Aurora 使用者指南》中的 Aurora Serverless v2 的最大連線數。
最佳實務：
-
預設設定 100% 適用於透過代理接收其所有流量的資料庫，且不需要管理存取或其他用戶端的任何標頭空間。
-
當資料庫也直接從應用程式 （繞過代理） 接收流量，而您不希望代理使用所有連線，或當您想要將特定數量的連線設定為不供資料庫管理員直接存取等其他用途時，請降低此設定。
-
搭配 Aurora Global Database 叢集使用 RDS Proxy 並啟用寫入轉送時，請將代理
MaxConnectionsPercent的值減少為分配給寫入轉送的配額。如需詳細資訊，請參閱《Amazon Aurora 使用者指南》中的 Aurora MySQL 和 Aurora PostgreSQL 中的寫入轉送組態參數。 PostgreSQL 此建議適用於代理服務全球資料庫主要或次要區域中的叢集。次要叢集可以提升為主要角色，因此最好在整個全域拓撲中保持代理設定的一致性。您可以針對提供主要與次要區域的代理使用非對稱設定，但在每次全域容錯移轉或切換之後，您將需要調整這些設定。 -
如果目標為多個代理提供服務，則所有代理
MaxConnectionsPercent的 合併值不得超過 100，以便資料庫不會過度訂閱。我們建議每個目標使用單一代理來簡化組態和管理。特別是，您不需要為每個資料庫使用多個代理進行備援。如需詳細資訊，請參閱將多個代理與一個目標搭配使用。
無論您是使用MaxConnectionsPercent預設設定或自訂值，請在允許的連線數與尖峰期間預期的用戶端連線數上限之間保留至少 30% 的前端空間。例如：
-
如果您認為代理最多需要為資料庫設定的連線限制的 50%，請使用至少
MaxConnectionsPercent的設定1.3 * 50% = 65%。 -
使用
MaxConnectionsPercent預設設定 100 時，請確定資料庫限制本身提供足夠的空間。
此額外空間可改善意外工作負載尖峰期間的客戶體驗，並協助 RDS Proxy 將連線重新分佈到其內部基礎設施，以進行熱管理和其他用途。
雖然您可以將 MaxConnectionsPercent設定為低至 1 的值，但根據執行個體類型，我們建議以下最小值：
db.t3.small：100
db.t3.medium：55
db.t3.large：35
db.r3.large 或以上：20
MaxIdleConnectionsPercent
| 最小值 | 最大值 | 預設值 (SQL Server) | 預設值 （其他引擎） |
|---|---|---|---|
| （零） | MaxConnectionsPercent | MaxConnectionsPercent 的 5% | MaxConnectionsPercent 的 50% |
如需詳細資訊，請參閱MaxIdleConnectionsPercent。
此設定會將 RDS Proxy 保留在連線集區中的閒置資料庫連線數限制為資料庫允許的最大連線數百分比。當連線上五分鐘沒有活動時，資料庫 （後端） 連線會被視為閒置。此設定適用於代理與後端資料庫之間的連線。
注意下列事項：
-
此設定會限制集區中的閒置連線數，但不會強制代理保留指定的閒置連線數。如果用戶端活動非常低，後端資料庫連線的實際數量可能會低於
MaxIdleConnectionsPercent。 -
當連線可在代理的連線集區中重複使用時，其會視為閒置。釘選連線無法供其他用戶端重複使用，因此不會為了強制執行 而計入閒置狀態
MaxIdleConnectionsPercent。如需鎖定的詳細資訊，請參閱 避免鎖定 RDS Proxy。 -
資料庫中繼資料報告的閒置連線數通常高於 RDS Proxy 指標記錄的閒置連線數。這可能是由於直接用戶端連線繞過代理，以及 Amazon RDS 和 Aurora 自動化所使用的內部連線。
注意
在代理層觀察到的和強制執行的連線閒置時間可能與資料庫工具報告的閒置時間不同，例如 MySQL 程序清單或 PostgreSQL 中的活動統計資料表。RDS Proxy 偶爾會 Ping 後端連線，即使連線在用戶端活動上保持閒置狀態，也會重設資料庫閒置計時器。
最佳實務：
預設設定 50 適合且建議用於大多數工作負載。變更設定具有下列效果：
-
當您提高 時
MaxIdleConnectionsPercent，資料庫會觀察更多閒置連線，這可能會增加尖峰時段以外的資料庫資源耗用量。另一方面，透過代理處理的連線峰值會遇到較低的借用延遲，因為集區中有更多連線可供使用。 -
當您降低 時
MaxIdleConnectionsPercent，代理會更積極地關閉閒置連線，進而減少這些連線所造成的爭用和資源消耗。不過，通過代理的連線尖峰可能會經歷較長的借用時間。由於集區中可用的連線較少，因此代理需要在尖峰期間花額外的時間開啟新的後端連線。
使用佈建執行個體類型的資料庫中，閒置連線的資源消耗可能不是重大考量，但使用 Serverless v2 執行個體類型的 Aurora 資料庫可能偏好最佳化閒置資源消耗，以降低成本。
IdleClientTimeout
| 最小值 | 最大值 | 預設值 |
|---|---|---|
| 1 分鐘 | 8 hours | 30 分鐘 |
如需詳細資訊，請參閱IdleClientTimeout。
此設定決定在代理關閉用戶端連線之前，用戶端連線可以保持閒置狀態的時間。請注意，RDS Proxy 會強制執行最長連線生命週期 24 小時，無論連線是否閒置。例如，如果您IdleClientTimeout將 設定為 30 分鐘 （預設） 並每分鐘 ping 資料庫，則連線永遠不會超過閒置逾時，但不會無限期保持開啟狀態。RDS Proxy 會在 24 小時後關閉連線，即使其不符合閒置資格。
此IdleClientTimeout設定適用於用戶端 （應用程式或互動式使用者） 與 RDS Proxy 之間的連線。若要了解 RDS Proxy 與資料庫之間後端連線的閒置行為，請參閱 MaxIdleConnectionsPercent。
最佳實務：
-
閒置逾時必須足夠長，以適應用戶端連線或交易內 SQL 活動中的正常暫停。它不能太長，以允許用戶端保留合理不再需要但其他用戶端可能需要的資源。如果您觀察到連線鎖定，這尤其重要，因為由一個用戶端鎖定的連線無法由其他用戶端重複使用。
-
若要讓 RDS Proxy 正確強制執行逾時，用戶端連線必須真正閒置，而不會傳送任何查詢 （即使是簡單的運作狀態檢查，例如
SELECT 1;) 或通訊協定 ping （例如 MySQLCOM_PING中的 )。如果您發現連線在超過逾時後仍未關閉，請檢查應用程式驅動程式的連線邏輯。應用程式層級連線集區特別可能執行自己的即時性檢查，干擾IdleClientTimeout。
ConnectionBorrowTimeout
| 最小值 | 最大值 | 預設值 |
|---|---|---|
| （零） | 5 分鐘 | 2 分鐘 |
如需詳細資訊，請參閱ConnectionBorrowTimeout。
當用戶端連線至 RDS Proxy 時，代理必須從集區借用現有的可用連線，或開啟新的資料庫連線。此設定定義 RDS Proxy 在傳回錯誤之前等待連線借用或開啟的時間。
注意下列事項：
-
當連線集區尚未包含可用的連線時，零
ConnectionBorrowTimeout的 會導致逾時錯誤。即使集區低於最大容量，並且可以開啟新的後端連線，也是如此。 -
即使
MaxIdleConnectionsPercent等於MaxConnectionsPercent，集區中的實際連線數仍可能低於設定的最大值。換句話說，MaxIdleConnectionsPercent會限制閒置連線的數量，但不會強制連線保持開啟。
連線集區執行低於最大容量是正常的。在這種情況下，使用ConnectionBorrowTimeout零的設定可防止集區成長，因為不允許集區等待開啟新的連線。因此，除非先前描述的行為是偏好的，否則您應該對所有工作負載使用非零ConnectionBorrowTimeout值。
注意
當資料庫尚未準備好接受連線時，例如離線維護操作和容錯移轉期間，也會套用此設定。無論資料庫為上或下，強制執行 的邏輯ConnectionBorrowTimeout都相同。
初始化查詢和鎖定篩選條件
RDS Proxy 支援其他功能，可減少連線鎖定並改善多工效率。
初始化查詢是每次代理設定新的後端資料庫連線時執行的一或多個陳述式。如果您的用戶端使用相同的陳述式來設定工作階段參數，您可以將這些陳述式移至代理的初始化查詢。這有助於降低鎖定機率，也可以提高效率：特定的後端資料庫連線會在設定期間執行其初始化查詢一次，但之後許多用戶端可能會重複使用。請記住，在初始化查詢中放置 SQL 陳述式並不會篩選掉用戶端流量。您仍然需要從應用程式程式碼中移除這些陳述式，才不會干擾多工。
工作階段鎖定篩選條件是一種組態屬性，可防止代理鎖定特定工作階段狀態。目前唯一可用的篩選選項 EXCLUDE_VARIABLE_SETS會指示代理在判斷是否應鎖定工作階段時忽略所有SET陳述式。SET 陳述式仍會傳遞至資料庫，並可能影響工作階段狀態，這表示此選項僅在下列情況中是安全的：
-
SET陳述式為無操作，例如將系統變數設定為與伺服器預設值相同的值。 -
SET陳述式和後續查詢是相同交易的一部分，每個交易都會完全獨立設定自己的狀態，因此不受其他交易設定的變數影響。
注意
EXCLUDE_VARIABLE_SETS 鎖定篩選條件是all-or-nothing設定，您無法選擇性地選擇要忽略的SET陳述式。除非您的使用案例屬於上述清單中討論的其中一個類別，否則請勿使用此篩選條件做為鎖定的括號解決方案。
為了獲得最佳結果，請盡可能從應用程式程式碼中移除不必要的陳述式，並只在無法修改應用程式時使用篩選條件。這可提升較不吵雜和較可預測的用戶端伺服器環境，而不是將特殊處理套用至一開始不需要的陳述式。
重要
初始化查詢或鎖定篩選條件都會導致 RDS Proxy 變更用戶端-伺服器查詢流量。無論初始化查詢或鎖定篩選條件組態為何，來自用戶端的陳述式仍會傳遞至資料庫。
如需詳細資訊，請參閱：
對於 PostgreSQL 連線，您也可以在用戶端驅動程式和代理之間交換的啟動訊息中放置支援的連線參數。這可避免傳送個別SET的命令，同時減少往返和避免明確SET陳述式所造成的連線鎖定。如需詳細資訊，請參閱連線至 PostgreSQL 的考量事項。
對齊應用程式、代理和資料庫組態
如上節所述，RDS Proxy 支援一系列參數，協助您將代理行為與您的應用程式需求保持一致。不過，選擇正確的組態值是跨堆疊的所有圖層剪下的任務：應用程式、代理和資料庫本身。所有這些元件的設定都必須符合下列目標：
-
在正常操作期間提供預期的效能和可擴展性層級。
-
在工作負載問題期間，提高疑難排解的清晰度和難易度。
-
協助堆疊處理意外事件 （例如工作負載突增），並將對應用程式的影響降至最低。
在多層環境中選擇和調校設定時，請嘗試對齊組態值，讓較低層的限制和逾時等於或高於較高層的對應限制和逾時。換言之，將來自一個 layer 的設定視為信封，可進一步放入下一個組態信封中。
例如，假設您的應用程式是頂層，代理是中間層，而資料庫是下層。如果代理層級的逾時和限制低於應用程式層級的限制，代理限制會先佔應用程式限制。應用程式無法執行其設定，並遇到無法透過其自身組態解釋的行為。
將IdleClientTimeout代理設定視為範例。如果您的應用程式驅動程式或用戶端集區強制執行自己的閒置逾時，則代理的閒置逾時是應用程式設定上的安全網路。這表示 IdleClientTimeout必須至少等於任何應用程式層級的閒置逾時，以避免混淆：
-
當應用程式閒置逾時低於代理逾時時，您預期應用程式會依設定關閉其連線。如果應用程式無法及時關閉閒置連線，代理會充當備用連線。
-
當應用程式閒置逾時超過代理逾時時，應用程式可能會遇到被視為過早的連線關閉。這可能會導致應用程式端混淆。
相同的邏輯適用於其他設定，例如連線限制：每個 layer 的設定都應該符合下一個 layer 組態所定義的信封內部。
為了獲得最佳結果，組態設定應該包含某個圖層與下一個圖層之間的一些填補。例如，您可以將代理逾時設為比應用程式逾時長幾秒鐘，以避免用戶端/伺服器時鐘偏離所造成的偶發錯誤，或者如果用戶端需要額外的時間來正常關閉連線。
換句話說，請像這樣調整您的設定：
client timeout < proxy timeout < database timeout
而不是這樣做：
client timeout = proxy timeout = database timeout
並避免這種情況：
client timeout > proxy timeout > database timeout
資料庫組態
連線限制
RDS Proxy 使用 MaxConnectionsPercent設定來判斷其連線集區的大小上限，這表示代理的連線集區大小相對於資料庫的連線限制。當您變更資料庫的連線限制時，代理的集區大小會自動跟隨。如果您希望資料庫為非代理使用者保留一部分連線限制，您應該降低代理中的MaxConnectionsPercent設定，而不是增加資料庫限制。
RDS Proxy 不會免除適當設定資料庫連線限制的需求。單一代理連線本質上不會比單一直接用戶端連線輕，因此請勿只因為您使用代理而增加資料庫限制。代理不會減少資料庫處理查詢時必須執行的工作量，但有助於資料庫使用較少的連線來處理相同的工作負載。
閒置逾時
資料庫可以強制執行自己的閒置逾時，例如，使用 MySQL 中的 wait_timeout和 interactive_timeout設定或 PostgreSQL 中的 transaction_timeout和 idle_in_transaction_session_timeout設定。這些設定的預設值不太可能干擾代理組態，但如果您使用自訂資料庫層級逾時，請確定它們至少只要對應的代理逾時，否則代理會因為過早逾時而遇到連線錯誤。
相同的邏輯適用於使用連線刪除程式的資料庫環境，這是監控工作階段狀態並根據特定條件主動終止連線的指令碼或程序。如果您的環境使用這類技術，請確定連線終止邏輯符合代理設定。
透過代理處理所有工作負載的資料庫通常可以依賴閒置逾時的代理組態，並將資料庫層級設定保留為預設值。
應用程式組態
管理工作階段狀態
許多資料庫驅動程式、應用程式架構和物件關聯映射 (ORM) 工具會使用工作階段變數或SET陳述式，在傳送查詢流量之前設定連線。單獨使用應用程式程式碼時，連線和交易初始化陳述式的使用可能不明顯，資料庫本身與 SQL 陳述式和應用程式邏輯之間可能會有多層抽象。您可以使用 RDS Proxy 增強型記錄功能來記錄連線鎖定的原因，而資料庫查詢日誌可以提供有關透過資料庫連線傳送之所有陳述式的進一步資訊。
請考慮下列最佳實務：
-
只有當連線參數與資料庫預設值不同，且用戶端工作階段必須偏離這些預設值時，才能設定連線參數。移除不必要的初始化陳述式不僅有助於多工，還可以減少每個新資料庫連線的用戶端伺服器往返次數。
-
在所有連線中一致地設定變數和組態設定。
-
避免也可以在查詢執行時間套用的工作階段組態。例如，如果不同的用戶端需要查看不同時區的資料，請考慮在查詢層級使用時區轉換函數，而不是在工作階段層級設定時區。
-
如果可能，請使用初始化查詢功能將工作階段組態陳述式移至代理層。如需詳細資訊，請參閱初始化查詢和鎖定篩選條件。
活體檢查
如果您的應用程式使用連線集區或進階驅動程式，請尋找與即時性檢查相關的組態，例如通訊協定 ping、運作狀態檢查陳述式或保持連線查詢。RDS Proxy 會平均處理所有用戶端請求，因此即使SELECT 1;查詢或COM_PING請求從應用程式角度而言是無操作，也可防止代理強制執行閒置用戶端逾時，並根據 管理連線集區大小MaxIdleConnectionsPercent。
注意
RDS Proxy 會強制執行最長連線生命週期 24 小時，無論連線上的活動為何。
在大多數情況下，可能適合停用用戶端活體檢查，以減少通訊協定雜訊，並協助 RDS Proxy 管理閒置連線。在某些情況下，您可能想要執行這些運作狀態檢查，無論：
-
您刻意想要防止代理層中的某些連線逾時。
-
您想要允許應用程式驅動程式或集區主動偵測代理何時捨棄連線。例如，鎖定的後端連線可能會因資料庫重新啟動而關閉，且用戶端連線可能會超過 24 小時的最長生命週期。
考慮在應用程式端停用活體檢查，或僅對您想要防止逾時的特定連線執行它們。
工作階段狀態追蹤
有些 MySQL 資料庫驅動程式，例如 MariaDB 驅動程式，使用session_track_*變數來啟用工作階段狀態的追蹤。啟用此功能後，每當用戶端進行伺服器可追蹤的工作階段狀態變更時，伺服器會在回應封包中包含狀態變更資訊。這可讓伺服器建議驅動程式工作階段狀態。
當用戶端直接與伺服器互動並實作自己的工作階段管理功能時，這種工作階段狀態追蹤方式可能很有意義，例如在多伺服器環境中進行工作階段遷移。RDS Proxy 會實作自己的狀態追蹤機制，不會使用session_track_*變數啟用的資訊，但設定這些變數會導致工作階段鎖定。
如果您的資料庫驅動程式設定這些變數，您可以尋找停用驅動程式中追蹤功能的方法、切換到不同的驅動程式，或使用工作階段鎖定篩選條件，在安全的情況下忽略陳述式。如需詳細資訊，請參閱初始化查詢和鎖定篩選條件。
