代管連線集區總覽

透過 Managed Connection Pooling，您可以最佳化 Cloud SQL 執行個體的資源用量和連線延遲時間，進而擴充工作負載。 PostgreSQL 會為每個連線建立新程序，這會導致記憶體用量和連線設定負擔。在經常建立許多短期連線的架構中 (例如在 Cloud Run 上執行的微服務或無伺服器應用程式)，這項額外負擔可能會影響資料庫效能和可擴充性。

啟用代管連線集區後，用戶端會連線至中介連線集區叢集，而非直接連線至資料庫伺服器。這項動態指派功能可吸收突然出現的連線尖峰，並重複使用現有的資料庫連線，因此能提升效能，特別是對於已擴充的連線。

連線集區器和連線集區

當用戶端應用程式連線至已啟用代管連線集區的執行個體時，會連線至中介連線集區叢集，而非直接連線至資料庫伺服器。連線集區叢集由一或多個連線集區器組成。連線集區是資料庫 Proxy 服務，可管理及路由用戶端應用程式和資料庫伺服器之間的資料庫連線。

連線集區管理工具會維護連線集區，做為每個資料庫和使用者配對的一組開放式可重複使用資料庫伺服器連線。

經過驗證的用戶端應用程式以特定使用者身分連線至資料庫時，連線集區器會將要求轉送至對應的連線集區：

  • 如果集區中有閒置的伺服器連線，連線集區管理工具就會將該連線指派給用戶端要求。
  • 如果沒有閒置的伺服器連線，且尚未達到集區限制 (max_pool_size)，連線集區器就會在集區中建立新的伺服器連線。
  • 如果集區中的所有伺服器連線都在使用中，且已達到集區限制，用戶端就會進入等待狀態，直到有可用的伺服器連線為止。
  • 要求完成後，伺服器連線會返回連線集區，以供重複使用。

集區管理員與集區之間的關係

單一連線集區器可同時管理多個連線集區，每個連線集區對應一組透過該集區器連線的專屬資料庫和資料庫使用者。

如果執行個體執行多個連線集區器，每個連線集區器會各自維護一組獨立的資料庫和使用者配對連線集區。

代管連線集區的效能和擴充功能在多個層級運作：

  • 連線集區叢集調度：叢集中的連線集區工具數量會根據為執行個體佈建的 vCPU 核心數量自動調度 (將 vCPU 數量除以 4，最少 1 個連線集區工具)。這可確保連線集區不會成為瓶頸。傳入的用戶端連線會分配給可用的連線集區器。例如：

    • 具有 2 個或 4 個 vCPU 的執行個體會執行 1 個連線集區。
    • 具有 8 個 vCPU 的執行個體會執行 2 個連線集區器。
    • 具有 16 個 vCPU 的執行個體會執行 4 個連線集區器。
    • 具有 32 個 vCPU 的執行個體會執行 8 個連線集區器。
    • 具有 64 個 vCPU 的執行個體會執行 16 個連線集區器。

  • 集區器和集區擴縮：由於連線集區器是獨立運作，因此所有設定選項都會套用至每個連線集區器，而不是整個執行個體。系統會視需要建立伺服器連線，每個連線集區的每個受管理集區最多可建立 max_pool_size 個連線。舉例來說，如果執行 2 個連線集區器 (8 個 vCPU) 的執行個體將 max_pool_size 設為 50，則每個連線集區器最多可為特定資料庫和使用者配對開啟 50 個伺服器連線，因此該集區的執行個體最多可有 100 個伺服器連線。準確設定集區大小對效能至關重要：如果這個值設定得太低，可能會導致連線等待時間變長；如果設定得太高，則可能會浪費資料庫伺服器資源。

  • 用戶端連線設定：每個連線集區也會設定用戶端連線限制和逾時行為。重要參數包括：

    • max_client_connections：限制每個連線集區允許的用戶端連線數量上限 (每個連線集區的預設值為 5,000 個連線)。
    • client_connection_idle_timeout：控制用戶端連線閒置多久後會逾時。
    • query_wait_timeout：控制查詢在集區中等待可用伺服器連線的時間長度，超過後就會逾時。

應用實例和注意事項

使用代管連線集區時，請注意下列事項：

  • 雖然您可以將代管連線集區用於任何交易工作負載，但對於含有短期連線的應用程式，或導致連線激增的應用程式，代管連線集區可提供最大的輸送量和延遲優勢。
  • 如果是長期連線，使用代管連線集區的連線效能可能會略低於直接連線。在這種情況下，當連線數量非常高時，代管連線集區會提供連線擴充功能。不過，對於通常會建立長期連線的應用程式，您可能不想使用連線集區。
  • 您可以根據代管連線集區使用的通訊埠，使用 Identity and Access Management 保護執行個體的連線。如要進一步瞭解 Cloud SQL 中的 IAM 運作方式和限制，請參閱「IAM 驗證」。

如要進一步瞭解如何啟用代管連線集區，請參閱「設定代管連線集區」。

需求條件

如要使用受管理連線集區，執行個體必須符合下列規定：

  • 執行個體必須是 Cloud SQL Enterprise Plus 版本執行個體。
  • 您必須僅使用直接連線或 Cloud SQL Auth Proxy 連線至執行個體。
  • 執行個體必須設定私人服務存取權、使用公開 IP，或是啟用 Private Service Connect 的新執行個體。
  • 執行個體必須使用新的 Cloud SQL 網路架構。
  • 代管連線集區的維護版本號碼至少須為 POSTGRES_$version.R20250727.00_14。如要進一步瞭解如何執行自助式維護，請參閱「執行自助式維護」。

彙整選項

您可以使用 pool_mode 參數，透過代管連線集區管理連線集區。您可以採用下列集區選項：

  • transaction (預設)：在交易層級集區連線。 每次交易完成後，連線都會返回集區。Cloud SQL 建議您對生命週期較短的連線使用transaction集區模式。
  • session：在工作階段層級集區連線。每個工作階段都會使用專屬的伺服器連線，以維持工作階段狀態。這會降低集區效率。用戶端中斷連線時，伺服器連線會返回連線集區。

進階設定選項

您可以使用下列設定選項， 自訂受管理連線共用。

設定名稱 說明
max_pool_size 每個連線集區中，資料庫和使用者配對允許的伺服器連線數上限。這項設定會套用至每個連線集區。請根據執行個體大小和集區大小需求決定這個值。

每個連線集區的預設值為每個資料庫和使用者配對 50 個連線。
min_pool_size 每個連線集區隨時可用的伺服器連線數量下限。這項設定會套用至每個連線集區。 根據執行個體大小和集區大小需求，決定這個值。

如果伺服器連線數少於 min_pool_size，這項設定會將更多伺服器連線新增至集區。這有助於管理非使用期間後資料庫負載突然增加的情況，並確保連線可用且隨時待命。

預設值為 0 個連線。
max_client_connections 使用代管連線集區時，每個連線集區器允許的用戶端連線數上限。請根據執行個體大小和集區大小需求，決定這個值。

每個連線集區的預設值為 5,000 個連線。
max_prepared_statements 在transaction集區模式中，每個連線集區器支援的通訊協定層級具名預備陳述式數量上限。根據執行個體大小和集區大小需求，決定這個值。

將這個選項設為 0，即可停用預先準備好的陳述式支援功能。為獲得最佳效能，這個值應超過資料庫中常用的預先編譯陳述式數量。如果代管連線集區中的預備陳述式數量過多，可能會導致記憶體用量增加。

預設值為 0 陳述式。
client_connection_idle_timeout 用戶端連線閒置多久後會逾時。 這個值可以介於 0 到 2,147,483 秒之間，預設值為 0 秒。
server_connection_idle_timeout 伺服器連線閒置多久後會逾時。 這個值可以介於 0 到 2,147,483 秒之間，預設值為 600 秒。
query_wait_timeout 查詢在集區中等待伺服器連線的時間，超過這個時間就會逾時。

將這個選項設為 0 即可停用，允許無限期排隊。啟用這個選項後，無回應的伺服器就不會阻礙連線。

這個值可以介於 0 到 2,147,483 秒之間，預設值為 120 秒。
ignore_startup_parameters 您要忽略的參數，這些參數預設不會在代管連線集區啟動封包中追蹤。
server_lifetime 伺服器連線閒置多久後，代管連線集區就會關閉連線。如果將值設為 0 秒，連線會在用完後立即關閉。

預設值為 3600 秒。

限制

搭配 Cloud SQL Enterprise Plus 版執行個體使用受管理連線集區時，請注意下列限制：

  • 在現有執行個體上啟用代管連線集區，會導致資料庫重新啟動。
  • 只有 Cloud SQL 驗證 Proxy 2.15.2 以上版本才能使用受管理連線集區。
  • 如果您使用 Cloud SQL Go 語言連接器，建議 Go 版本至少為 1.24。如果您使用 Go 1.23 以下版本，使用代管連線集區時可能會遇到效能限制。

  • 如果您在 transaction 集區模式中使用 Managed Connection Pooling，則不支援下列 SQL 功能：

    • SET/RESET
    • LISTEN
    • WITH HOLD CURSOR
    • PREPARE/DEALLOCATE
    • PRESERVE/DELETE ROW 臨時資料表
    • LOAD
    • 工作階段層級的諮詢鎖定

  • 如果您使用 asyncpg 資料庫介面程式庫，透過 3307 和 6432 連接埠，在 Managed Connection Pooling 集區器上執行作業，則必須將 max_prepared_statements 更新為大於 0 的值，才能在 Managed Connection Pooling 集區器中啟用預先準備好的陳述式。

  • 如果您使用 PostgreSQL 適用的 Cloud SQL 17 版，則系統不支援 sslnegotiation=direct 選項。

  • 代管連線集區不支援追蹤用戶端 IP。如果您在查詢洞察中啟用「儲存用戶端 IP 位址」，系統會以 local 顯示用戶端 IP 位址，而非實際的 IP 位址。

代管連線集區使用的通訊埠

啟用「受管理連線集區」後，Cloud SQL 執行個體用於處理資料庫流量的通訊埠會變更。您可以視連接埠而定，使用 Identity and Access Management 保護連線。

代管連線集區使用的通訊埠和可用的 IAM 選項如下：

  • TCP 通訊埠 5432：Postgres 資料庫伺服器用於直接連線。這是使用 psql 用戶端直接連線的預設通訊埠編號。

  • TCP 通訊埠 6432：代管連線集區伺服器用於直接連線。如要使用這個通訊埠連線，請在使用 psql 用戶端直接連線時指定 psql -p 6432。

    使用這個通訊埠時，您可以採用任何 IAM 驗證方法。

  • TCP 通訊埠 3307：僅供 Managed Connection Pooling 伺服器使用 Cloud SQL Auth Proxy 連線。使用 Cloud SQL Auth Proxy 連線至 Managed Connection Pooling 時，這個通訊埠號碼會透過 Cloud SQL Auth Proxy 用戶端設定，且無法變更。

    您可以使用任何IAM 驗證選項，或透過這個連接埠自動進行 IAM 資料庫驗證。

代管連線集區使用的伺服器連線

max_connections 資料庫設定會限制代管連線集區中的集區器可使用的伺服器連線數量上限。Cloud SQL 建議根據執行個體的工作負載需求和資料庫執行個體大小調整這個值。負載尖峰期間，驗證連線數量可能會非常高。

如果您使用預設的每個集區max_pool_size 50 個連線，建議您為資料庫設定 max_connections 旗標時，為受管理連線集區保留每個 CPU 至少 15 個伺服器連線。如要進一步瞭解 max_connections 標記，請參閱「並行連線數量上限」。如要修改執行個體的 max_connections 旗標，請參閱「設定資料庫旗標」。

後續步驟