Verwaltetes Verbindungs-Pooling – Übersicht

Mit verwaltetem Verbindungs-Pooling können Sie Ihre Arbeitslasten skalieren, indem Sie die Ressourcennutzung und die Verbindungs-Latenz für Ihre Cloud SQL-Instanzen optimieren. PostgreSQL erstellt für jede Verbindung einen neuen Prozess, was zu einer höheren Arbeitsspeichernutzung und einem höheren Aufwand für die Einrichtung der Verbindung führt. In Architekturen, in denen häufig viele kurzlebige Verbindungen hergestellt werden, z. B. bei Microservices oder serverlosen Anwendungen, die in Cloud Run ausgeführt werden, kann sich dieser Aufwand auf die Datenbankleistung und -skalierbarkeit auswirken.

Wenn verwaltetes Verbindungs-Pooling aktiviert ist, stellen Clients eine Verbindung zu einem Cluster mit Verbindungspools her, anstatt direkt eine Verbindung zum Datenbankserver herzustellen. 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 Cluster mit Verbindungspools her, anstatt direkt eine Verbindung zum Datenbankserver herzustellen. Der Cluster mit Verbindungspools besteht aus einem oder mehreren Verbindungspoolern. Ein Verbindungspooler ist ein Datenbank-Proxydienst, 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) noch nicht erreicht wurde, erstellt der Verbindungspooler eine neue Serververbindung im Pool.
  • Wenn alle Serververbindungen im Pool verwendet werden und das Poollimit erreicht wurde, wechselt der Client in einen Wartezustand, bis eine Serververbindung verfügbar wird.
  • Nach Abschluss der Anfrage wird die Serververbindung zur Wiederverwendung an den Verbindungspool zurückgegeben.

Beziehung zwischen Poolern und Pools

Ein einzelner Verbindungspooler kann mehrere Verbindungspools gleichzeitig verwalten, wobei ein Pool für jedes eindeutige Datenbank- und Datenbanknutzerpaar vorhanden ist, das eine Verbindung über diesen Pooler herstellt.

Wenn in Ihrer Instanz mehrere Verbindungspooler ausgeführt werden, verwaltet jeder Verbindungspooler unabhängig eine eigene Gruppe von Verbindungspools für die Datenbank- und Nutzerpaare, die an ihn weitergeleitet werden.

Die Leistung und Skalierbarkeit des verwalteten Verbindungs-Poolings funktionieren auf mehreren Ebenen:

  • Skalierung des Clusters mit Verbindungspools:Die Anzahl der Verbindungspooler im Cluster wird automatisch basierend auf der Anzahl der für die Instanz bereitgestellten vCPU-Cores skaliert (Anzahl der vCPUs geteilt durch 4, mindestens 1 Verbindungspooler). 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.
    • Eine Instanz mit 8 vCPUs führt 2 Verbindungspooler aus.
    • 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.

  • Skalierung von Poolern und Pools:Da Verbindungspooler unabhängig voneinander arbeiten, werden alle Konfigurationsoptionen pro Verbindungspooler und nicht global für die Instanz angewendet. Serververbindungen werden bei Bedarf bis zu einem durch max_pool_size definierten Limit für jeden verwalteten Pool in jedem Verbindungspooler erstellt. Wenn max_pool_size beispielsweise auf 50 für eine Instanz mit 2 Verbindungspoolern (8 vCPUs) festgelegt ist, kann jeder Verbindungspooler bis zu 50 Serververbindungen für ein bestimmtes Datenbank- und Nutzerpaar öffnen, sodass insgesamt bis zu 100 Serververbindungen für diesen Pool in der Instanz möglich sind. Die richtige Poolgröße ist entscheidend für die Leistung. 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:Grenzwerte für Clientverbindungen und das Timeout-Verhalten werden ebenfalls pro Verbindungspooler konfiguriert. Wichtige Parameter sind:

    • max_client_connections: begrenzt die maximale Anzahl der zulässigen Clientverbindungen pro Verbindungspooler (der Standardwert ist 5.000 Verbindungen für jeden Verbindungspooler).
    • client_connection_idle_timeout: steuert die Dauer, die eine Clientverbindung inaktiv bleiben kann, bevor sie unterbrochen wird.
    • query_wait_timeout: steuert die Dauer, die eine Abfrage auf eine verfügbare Serververbindung im Pool wartet, bevor sie unterbrochen wird.

Anwendungsfälle und Überlegungen

Beachten Sie Folgendes, wenn Sie verwaltetes Verbindungs-Pooling verwenden:

  • Sie können verwaltetes Verbindungs-Pooling für alle transaktionalen Arbeitslasten verwenden. Es bietet jedoch den größten Durchsatz- und Latenzvorteil für Anwendungen mit kurzlebigen Verbindungen oder Anwendungen, die zu einem plötzlichen Anstieg der Verbindungen führen.
  • Bei langlebigen Verbindungen kann die Verbindungsleistung mit verwaltetem Verbindungs-Pooling etwas geringer sein als bei einer direkten Verbindung. In diesem Fall bietet verwaltetes Verbindungs-Pooling eine Verbindungsskalierung, wenn die Anzahl der Verbindungen sehr hoch ist. Bei Anwendungen, die in der Regel langlebige Verbindungen herstellen, sollten Sie jedoch möglicherweise kein Verbindungs-Pooling verwenden.
  • Sie können Identity and Access Management verwenden, um Verbindungen zu Ihrer Instanz zu sichern, je nach dem Port, der vom verwalteten Verbindungs-Pooling verwendet wird. 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 verwaltetes 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 nur über eine direkte Verbindung oder 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 muss aktiviert sein.
  • Ihre Instanz muss die neue Cloud SQL-Netzwerkarchitektur verwenden.
  • Für verwaltetes Verbindungs-Pooling ist eine Wartungsversion von mindestens 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 verwaltetem Verbindungs-Pooling können Sie mit dem Parameter pool_mode verwalten, wie Verbindungen gepoolt werden. Sie haben die folgenden Pooling-Optionen:

  • transaction (Standard): Verbindungen werden auf Transaktionsebene gepoolt. Verbindungen werden nach Abschluss jeder Transaktion an den Pool zurückgegeben. Cloud SQL empfiehlt, den Pooling-Modus transaction für kurzlebige Verbindungen zu verwenden.
  • session: Verbindungen werden auf Sitzungsebene gepoolt. Jede Sitzung verwendet eine dedizierte Serververbindung, 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

Sie können verwaltetes Verbindungs-Pooling mit den folgenden Konfigurationsoptionen anpassen.

Konfigurationsname Beschreibung
max_pool_size Die maximale Anzahl von Serververbindungen, die für ein Datenbank- und Nutzer paar in jedem Verbindungspool zulässig sind. Diese Konfiguration wird pro Verbindungspooler angewendet. Legen Sie diesen Wert basierend auf der Instanzgröße und den Anforderungen an die Poolgröße fest.

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 der Instanzgröße und den Anforderungen an die Poolgröße fest.

Wenn die Anzahl der Serververbindungen kleiner als die min_pool_size ist, werden mit dieser Einstellung weitere Server Verbindungen zum Pool hinzugefügt. So können Sie plötzliche Anstiege der Datenbanklast nach Phasen der Inaktivität verwalten und sicherstellen, 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. Legen Sie diesen Wert basierend auf der Instanzgröße und den Anforderungen an die Poolgröße fest.

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 transaction Pooling-Modus unterstützt werden. Legen Sie diesen Wert basierend auf der Instanzgröße und den Anforderungen an 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 übersteigen. Eine hohe Anzahl vorbereiteter Anweisungen beim verwalteten Verbindungs-Pooling kann zu einer erhöhten Arbeitsspeichernutzung führen.

Der Standardwert ist 0 Anweisungen.
client_connection_idle_timeout Die Zeit, die eine Clientverbindung inaktiv bleibt, bevor sie unterbrochen wird. 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 sie unterbrochen wird.

Wenn Sie diese Option auf 0 setzen, wird sie deaktiviert, wodurch eine unbegrenzte Client Warteschlange möglich ist. 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 verwaltetes 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 ist 3600 Sekunden.

Beschränkungen

Beachten Sie bei der Verwendung des verwalteten Verbindungs-Poolings mit Ihren Cloud SQL Enterprise Plus-Instanzen 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 dem 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 des verwalteten Verbindungs-Poolings zu Leistungseinschränkungen kommen.

  • Wenn Sie verwaltetes Verbindungs-Pooling im Pooling-Modus transaction 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 des verwalteten Verbindungs-Poolings auf den Ports 3307 und 6432 verwenden, müssen Sie die max_prepared_statements auf einen Wert größer als 0 aktualisieren, um die Unterstützung für vorbereitete Anweisungen im Pooler des verwalteten Verbindungs-Poolings zu aktivieren.

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

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

Ports, die vom verwalteten Verbindungs-Pooling verwendet werden

Wenn Sie verwaltetes Verbindungs-Pooling aktivieren, ändern sich die Ports, die von Cloud SQL-Instanzen verwendet werden, um Datenbanktraffic zu verarbeiten. Sie können Identity and Access Management verwenden, um Verbindungen je nach Port zu sichern.

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

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 basierend auf den Arbeitslastanforderungen Ihrer Instanz und der Größe der Datenbankinstanz anzupassen. Bei Spitzenlast kann die Anzahl der Verbindungen für die Authentifizierung sehr hoch sein.

Wenn Sie die Standardeinstellung max_pool_size von 50 Verbindungen pro Pool verwenden, empfehlen wir, mindestens 15 Serververbindungen pro CPU für das verwaltete 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 Ändhing des max_connections Flags für Ihre Instanz, siehe Datenbank-Flags konfigurieren.

Nächste Schritte