Verwaltetes Verbindungs-Pooling – Übersicht

Mit verwaltetem Verbindungs-Pooling können Sie Ihre Arbeitslasten skalieren, indem Sie die Ressourcennutzung und die Verbindungslatenz für Ihre Cloud SQL-Instanzen optimieren. PostgreSQL erstellt für jede Verbindung einen neuen Prozess, was zu Arbeitsspeichernutzung und Mehraufwand für die Verbindungseinrichtung führt. In Architekturen, die häufig viele kurzlebige Verbindungen herstellen, z. B. bei Mikrodiensten oder serverlosen Anwendungen, die in Cloud Run ausgeführt werden, kann dieser Overhead die Datenbankleistung und ‑skalierbarkeit beeinträchtigen.

Wenn das verwaltete Verbindungs-Pooling aktiviert ist, stellen Clients eine Verbindung zu einem zwischengeschalteten Verbindungspool-Cluster her, anstatt sich direkt mit dem Datenbankserver zu verbinden. Diese dynamische Zuweisung führt zu Leistungsverbesserungen, insbesondere bei skalierten Verbindungen, da plötzliche Verbindungsspitzen abgefangen und vorhandene Datenbankverbindungen wiederverwendet werden.

Verbindungspooler und Verbindungspools

Wenn Clientanwendungen eine Verbindung zu einer Instanz mit aktiviertem verwaltetem Verbindungs-Pooling herstellen, stellen sie eine Verbindung zu einem zwischengeschalteten Verbindungspool-Cluster her, anstatt sich direkt mit dem Datenbankserver zu verbinden. Der Verbindungspool-Cluster besteht aus einem oder mehreren Verbindungspoolern. Ein Verbindungspooler ist ein Datenbank-Proxy-Dienst, der Datenbankverbindungen zwischen Clientanwendungen und dem Datenbankserver verwaltet und weiterleitet.

Ein Verbindungspooler verwaltet Verbindungspools als Gruppe offener, wiederverwendbarer Datenbankserververbindungen pro Datenbank- und Nutzerpaar.

Wenn eine authentifizierte Clientanwendung als bestimmter Nutzer eine Verbindung zu einer Datenbank herstellt, leitet der Verbindungspooler die Anfrage an den entsprechenden Verbindungspool weiter:

  • Wenn im Pool eine inaktive Serververbindung verfügbar ist, weist der Verbindungspooler sie der Clientanfrage zu.
  • Wenn keine inaktive Serververbindung verfügbar ist und das Poollimit (max_pool_size) nicht erreicht wurde, erstellt der Verbindungs-Pooler eine neue Serververbindung im Pool.
  • Wenn alle Serververbindungen im Pool verwendet werden und das Poollimit erreicht ist, wechselt der Client in einen Wartestatus, bis eine Serververbindung verfügbar ist.
  • Wenn die Anfrage abgeschlossen ist, wird die Serververbindung zur Wiederverwendung an den Verbindungspool zurückgegeben.

Beziehung zwischen Poolern und Pools

Ein einzelner Verbindungspooler kann mehrere Verbindungspools gleichzeitig verwalten. Dabei gibt es einen Pool für jedes eindeutige Datenbank- und Datenbanknutzerpaar, das über diesen Pooler eine Verbindung herstellt.

Wenn auf Ihrer Instanz mehrere Verbindungspooler ausgeführt werden, verwaltet jeder Verbindungspooler unabhängig voneinander einen eigenen Satz von Verbindungspools für die Datenbank- und Nutzerpaare, die an ihn weitergeleitet werden.

Die Leistungs- und Skalierungsfunktionen des verwalteten Verbindungs-Poolings funktionieren auf mehreren Ebenen:

  • Skalierung des Verbindungspool-Clusters: Die Anzahl der Verbindungspooler im Cluster wird automatisch basierend auf der Anzahl der für die Instanz bereitgestellten vCPU-Kerne skaliert. Dazu wird die vCPU-Anzahl durch 4 geteilt, wobei mindestens ein Verbindungspooler vorhanden sein muss. So wird verhindert, dass das Verbindungs-Pooling zu einem Engpass wird. Eingehende Clientverbindungen werden auf die verfügbaren Verbindungspooler verteilt. Beispiel:

    • Eine Instanz mit 2 oder 4 vCPUs führt 1 Verbindungspooler aus.
    • Auf einer Instanz mit 8 vCPUs werden 2 Verbindungspooler ausgeführt.
    • Eine Instanz mit 16 vCPUs führt 4 Verbindungspooler aus.
    • Eine Instanz mit 32 vCPUs führt 8 Verbindungspooler aus.
    • Eine Instanz mit 64 vCPUs führt 16 Verbindungspooler aus.

  • Pooler- und Poolskalierung: Da Verbindungspooler unabhängig voneinander arbeiten, werden alle Konfigurationsoptionen pro Verbindungspooler und nicht global für die gesamte Instanz angewendet. Serververbindungen werden bei Bedarf bis zu einem maximalen Limit erstellt, das durch max_pool_size für jeden verwalteten Pool in jedem Verbindungspooler definiert wird. Wenn max_pool_size beispielsweise auf einer Instanz mit 2 Verbindungspoolern (8 vCPUs) auf 50 festgelegt ist, kann jeder Verbindungspooler bis zu 50 Serververbindungen für ein bestimmtes Datenbank- und Nutzerpaar öffnen. Dadurch sind insgesamt bis zu 100 Serververbindungen über die Instanz für diesen Pool möglich. Die genaue Dimensionierung des Pools ist für die Leistung entscheidend: Wenn Sie diesen Wert zu niedrig festlegen, kann dies zu längeren Wartezeiten für Verbindungen führen. Wenn Sie ihn zu hoch festlegen, können Datenbankserverressourcen verschwendet werden.

  • Konfigurationen für Clientverbindungen: Limits für Clientverbindungen und das Zeitlimitverhalten werden ebenfalls pro Verbindungspooler konfiguriert. Wichtige Parameter:

    • max_client_connections: Begrenzt die maximale Anzahl von Clientverbindungen,die pro Verbindungspooler zulässig sind. Der Standardwert ist 5.000 Verbindungen pro Verbindungspooler.
    • client_connection_idle_timeout: Steuert die Dauer, die eine Clientverbindung inaktiv bleiben kann, bevor sie das Zeitlimit überschreitet.
    • query_wait_timeout: Steuert die Dauer, die eine Abfrage auf eine verfügbare Serververbindung im Pool wartet, bevor eine Zeitüberschreitung auftritt.

Anwendungsfälle und Überlegungen

Beachten Sie bei der Verwendung von verwaltetem Verbindungs-Pooling Folgendes:

  • Sie können verwaltetes Verbindungs-Pooling für jede transaktionale Arbeitslast verwenden. Es bietet jedoch den größten Durchsatz- und Latenzvorteil für Anwendungen mit kurzlebigen Verbindungen oder für Anwendungen, bei denen es zu einem plötzlichen Anstieg der Verbindungen kommen kann.
  • Bei langlebigen Verbindungen kann die Verbindungsleistung mit verwaltetem Verbindungs-Pooling etwas geringer sein als bei einer direkten Verbindung. In diesem Fall bietet das verwaltete Verbindungs-Pooling eine Verbindungsskalierung, wenn die Anzahl der Verbindungen sehr hoch ist. Bei Anwendungen, die in der Regel langlebige Verbindungen herstellen, sollten Sie jedoch die Verwendung von Verbindungs-Pooling vermeiden.
  • Sie können Identity and Access Management verwenden, um Verbindungen zu Ihrer Instanz zu sichern, je nachdem, welchen Port das verwaltete Verbindungs-Pooling verwendet. Weitere Informationen zur Funktionsweise von IAM in Cloud SQL und zu den Einschränkungen finden Sie unter IAM-Authentifizierung.

Weitere Informationen zum Aktivieren des verwalteten Verbindungs-Poolings finden Sie unter Verwaltetes Verbindungs-Pooling konfigurieren.

Voraussetzungen

Damit Sie das verwaltete Verbindungs-Pooling verwenden können, muss Ihre Instanz die folgenden Anforderungen erfüllen:

  • Ihre Instanz muss eine Cloud SQL Enterprise Plus-Instanz sein.
  • Sie müssen entweder über eine direkte Verbindung oder über den Cloud SQL Auth-Proxy mit Ihrer Instanz verbunden sein.
  • Ihre Instanz muss für den Zugriff auf private Dienste eingerichtet sein, eine öffentliche IP-Adresse verwenden oder Private Service Connect aktiviert haben.
  • Ihre Instanz muss die neue Cloud SQL-Netzwerkarchitektur verwenden.
  • Für das verwaltete Verbindungs-Pooling ist eine Mindestwartungsversion von POSTGRES_$version.R20250727.00_14 erforderlich. Weitere Informationen zur Durchführung der Self-Service-Wartung finden Sie unter Self-Service-Wartung durchführen.

Pooling-Optionen

Mit dem verwalteten Verbindungs-Pooling können Sie mit dem Parameter pool_mode festlegen, wie Verbindungen zusammengefasst werden. Sie können die folgenden Pooling-Optionen verwenden:

  • transaction (Standard): Verbindungen werden auf Transaktionsebene zusammengefasst. Verbindungen werden nach Abschluss jeder Transaktion an den Pool zurückgegeben. Cloud SQL empfiehlt die Verwendung des Pooling-Modus transaction für kurzlebige Verbindungen.
  • session: Verbindungen werden auf Sitzungsebene zusammengefasst. Für jede Sitzung wird eine dedizierte Serververbindung verwendet, die einen Sitzungsstatus beibehält. Dadurch wird die Pooling-Effizienz verringert. Wenn ein Client die Verbindung trennt, wird die Serververbindung an den Verbindungspool zurückgegeben.

Erweiterte Konfigurationsoptionen

Mit den folgenden Konfigurationsoptionen können Sie das Pooling verwalteter Verbindungen anpassen.

Konfigurationsname Beschreibung
max_pool_size Die maximale Anzahl von Serververbindungen, die für ein Datenbank- und Nutzerpaar in jedem Verbindungspool zulässig sind. Diese Konfiguration wird pro Verbindungspooler angewendet. Bestimmen Sie diesen Wert anhand Ihrer Anforderungen an die Instanzgröße und die Poolgröße.

Der Standardwert ist 50 Verbindungen pro Datenbank- und Nutzerpaar für jeden Verbindungspooler.
min_pool_size Die Mindestanzahl von Serververbindungen, die jederzeit in jedem Verbindungspool verfügbar sind. Diese Konfiguration wird pro Verbindungspooler angewendet. Legen Sie diesen Wert basierend auf Ihren Anforderungen an die Instanzgröße und die Poolgröße fest.

Wenn die Anzahl der Serververbindungen kleiner als der min_pool_size ist, werden dem Pool durch diese Einstellung weitere Serververbindungen hinzugefügt. So lassen sich plötzliche Anstiege der Datenbanklast nach Phasen der Inaktivität besser bewältigen und es wird sichergestellt, dass Verbindungen verfügbar und einsatzbereit sind.

Der Standardwert ist 0 Verbindungen.
max_client_connections Die maximale Anzahl von Clientverbindungen, die pro Verbindungspooler zulässig sind, wenn verwaltetes Verbindungs-Pooling verwendet wird. Bestimmen Sie diesen Wert anhand Ihrer Anforderungen an die Instanzgröße und die Poolgröße.

Der Standardwert ist 5,000 Verbindungen für jeden Verbindungspooler.
max_prepared_statements Die maximale Anzahl von benannten vorbereiteten Anweisungen auf Protokollebene, die pro Verbindungspooler im Pooling-Modus transaction unterstützt werden. Legen Sie diesen Wert basierend auf Ihren Anforderungen an die Instanzgröße und die Poolgröße fest.

Wenn Sie diese Option auf 0 setzen, wird die Unterstützung für vorbereitete Anweisungen deaktiviert. Für eine optimale Leistung sollte dieser Wert die Anzahl der häufig verwendeten vorbereiteten Anweisungen in Ihrer Datenbank überschreiten. Eine hohe Anzahl von vorbereiteten Anweisungen im verwalteten Verbindungs-Pooling kann zu einer erhöhten Speichernutzung führen.

Der Standardwert ist 0 Anweisungen.
client_connection_idle_timeout Die Zeit, die eine Clientverbindung inaktiv bleibt, bevor sie das Zeitlimit überschreitet. Dieser Wert kann zwischen 0 und 2,147,483 Sekunden liegen. Der Standardwert ist 0 Sekunden.
server_connection_idle_timeout Die Zeit, die eine Serververbindung inaktiv bleibt, bevor sie unterbrochen wird. Dieser Wert kann zwischen 0 und 2,147,483 Sekunden liegen. Der Standardwert ist 600 Sekunden.
query_wait_timeout Die Zeit, die eine Abfrage auf eine Serververbindung in einem Pool wartet, bevor das Zeitlimit überschritten wird.

Wenn Sie diese Option auf 0 setzen, wird sie deaktiviert, sodass Clients unbegrenzt in die Warteschlange gestellt werden können. Wenn Sie diese Option aktivieren, wird verhindert, dass nicht reagierende Server Verbindungen blockieren.

Dieser Wert kann zwischen 0 und 2,147,483 Sekunden liegen. Der Standardwert ist 120 Sekunden.
ignore_startup_parameters Die Parameter, die ignoriert werden sollen und die standardmäßig nicht in den Startpaketen für das verwaltete Verbindungs-Pooling erfasst werden.
server_lifetime Die maximale Zeit, die eine Serververbindung ungenutzt bleibt, bevor sie durch das verwaltete Verbindungs-Pooling geschlossen wird. Wenn der Wert auf 0 Sekunden festgelegt ist, wird die Verbindung sofort nach der Verwendung geschlossen.

Der Standardwert beträgt 3600 Sekunden.

Beschränkungen

Wenn Sie Managed Connection Pooling mit Ihren Cloud SQL Enterprise Plus-Instanzen verwenden, beachten Sie die folgenden Einschränkungen:

  • Wenn Sie verwaltetes Verbindungs-Pooling für eine vorhandene Instanz aktivieren, wird die Datenbank neu gestartet.
  • Verwaltetes Verbindungs-Pooling kann nur mit Cloud SQL Auth-Proxy Version 2.15.2 und höher verwendet werden.
  • Wenn Sie den Cloud SQL Go Language Connector verwenden, empfehlen wir mindestens die Go-Version 1.24. Wenn Sie Go-Version 1.23 oder früher verwenden, kann es bei der Verwendung von verwaltetem Verbindungs-Pooling zu Leistungseinschränkungen kommen.

  • Wenn Sie verwaltetes Verbindungs-Pooling im transaction-Pooling-Modus verwenden, werden die folgenden SQL-Funktionen nicht unterstützt:

    • SET/RESET
    • LISTEN
    • WITH HOLD CURSOR
    • PREPARE/DEALLOCATE
    • PRESERVE/DELETE ROW Temporäre Tabellen
    • LOAD
    • Advisory-Sperren auf Sitzungsebene

  • Wenn Sie die asyncpg-Datenbankschnittstellenbibliothek für den Pooler für verwaltetes Verbindungs-Pooling auf Port 3307 und 6432 verwenden, müssen Sie max_prepared_statements auf einen Wert größer als 0 aktualisieren, um die Unterstützung für vorbereitete Anweisungen im Pooler für verwaltetes Verbindungs-Pooling zu aktivieren.

  • Wenn Sie Cloud SQL for PostgreSQL Version 17 verwenden, wird die Option sslnegotiation=direct nicht unterstützt.

  • Das Tracking von Client-IP-Adressen wird beim verwalteten Verbindungs-Pooling nicht unterstützt. Wenn Sie Client-IP-Adressen speichern in Query Insights aktivieren, werden Client-IP-Adressen als local anstelle der IP-Adresse selbst angezeigt.

Von verwaltetem Verbindungs-Pooling verwendete Ports

Wenn Sie Managed Connection Pooling aktivieren, ändern sich die Ports, die von Cloud SQL-Instanzen für den Datenbanktraffic verwendet werden. Je nach Port können Sie Identity and Access Management verwenden, um Verbindungen zu sichern.

Die vom verwalteten Verbindungs-Pooling verwendeten Ports und die verfügbaren IAM-Optionen sind:

  • TCP-Port 5432: Wird für direkte Verbindungen vom Postgres-Datenbankserver verwendet. Dies ist die Standardportnummer für die direkte Verbindung über den psql-Client.

  • TCP-Port 6432: Wird vom verwalteten Verbindungspooling-Server für direkte Verbindungen verwendet. Wenn Sie eine Verbindung über diesen Port herstellen möchten, geben Sie psql -p 6432 an, wenn Sie eine direkte Verbindung über den psql-Client herstellen.

    Sie können jede IAM-Authentifizierungsoption verwenden, wenn Sie diesen Port verwenden.

  • TCP-Port 3307: Wird nur für Cloud SQL Auth-Proxy-Verbindungen von einem Managed Connection Pooling-Server verwendet. Wenn Sie den Cloud SQL Auth-Proxy verwenden, um eine Verbindung zum verwalteten Verbindungs-Pooling herzustellen, wird diese Portnummer mit dem Cloud SQL Auth-Proxy-Client konfiguriert und kann nicht geändert werden.

    Sie können jede IAM-Authentifizierungsoption oder die automatische IAM-Datenbankauthentifizierung mit diesem Port verwenden.

Serververbindungen, die vom verwalteten Verbindungs-Pooling verwendet werden

Die Datenbankkonfiguration max_connections begrenzt die maximale Anzahl von Serververbindungen, die ein Pooler im verwalteten Verbindungs-Pooling verwenden kann. Cloud SQL empfiehlt, diesen Wert an die Arbeitslastanforderungen Ihrer Instanz und die Größe der Datenbankinstanz anzupassen. Bei Spitzenlast kann die Anzahl der Verbindungen für die Authentifizierung sehr hoch sein.

Wenn Sie den Standardwert max_pool_size von 50 Verbindungen pro Pool verwenden, empfehlen wir, mindestens 15 Serververbindungen pro CPU für verwaltetes Verbindungs-Pooling zu reservieren, wenn Sie das Flag max_connections für Ihre Datenbank festlegen. Weitere Informationen zum Flag max_connections finden Sie unter Maximale Anzahl gleichzeitiger Verbindungen. Informationen zum Ändern des Flags max_connections für Ihre Instanz finden Sie unter Datenbank-Flags konfigurieren.

Nächste Schritte