PgBouncer in Azure Database for PostgreSQL – Flexible Server

  • Artikel

GILT FÜR: Azure Database for PostgreSQL – Flexibler Server

Der flexible Server von Azure Database for PostgreSQL bietet PgBouncer als integrierte Lösung für das Verbindungspooling an. PgBouncer ist ein optionales Feature, das Sie pro Datenbankserver aktivieren können. Es wird auf den Computeebenen „Universell“ und „Arbeitsspeicheroptimiert“ sowohl in Netzwerken mit öffentlichem als auch mit privatem Zugriff unterstützt.

PgBouncer wird auf demselben virtuellen Computer (VM) wie der Datenbankserver für Azure Database for PostgreSQL – Flexible Server ausgeführt. Postgres verwendet ein prozessbasiertes Modell für Verbindungen, sodass die Aufrechterhaltung vieler Leerlaufverbindungen teuer ist. Postgres stößt auf Ressourcenbeschränkungen, wenn der Server mehr als ein paar tausend Verbindungen hat. Der primäre Nutzen von PgBouncer ist die Verbesserung von Leerlaufverbindungen und kurzlebigen Verbindungen am Datenbankserver.

PgBouncer verwendet ein einfaches Modell, das asynchrone E/A verwendet. Es verwendet Postgres-Verbindungen nur bei Bedarf, d. h. innerhalb einer geöffneten Transaktion oder wenn eine Abfrage aktiv ist. Dieses Modell ermöglicht die Skalierung auf bis zu 10.000 Verbindungen mit geringen Mehrkosten.

PgBouncer läuft auf Port 6432 auf Ihrem Datenbankserver. Sie können die Datenbankverbindungskonfiguration Ihrer Anwendung so ändern, dass derselbe Hostname verwendet wird, aber der Port auf 6432 geändert wird, um PgBouncer zu verwenden und von der verbesserten Skalierung der Leerlaufverbindungen zu profitieren.

PgBouncer in der Azure Database for PostgreSQL – Flexible Server unterstützt die Authentifizierung mit Microsoft Entra (Azure AD).

Aktivieren und Konfigurieren von Protokollen

Um PgBouncer zu aktivieren, wechseln Sie zum Bereich Serverparameter im Azure-Portal, suchen Sie nach PgBouncer und ändern Sie die pgbouncer.enabled-Einstellung zu true. Sie müssen den Computer nicht neu starten.

Sie können PgBouncer und Einstellungen mithilfe der folgenden Parameter konfigurieren.

Hinweis

Die folgende Liste der PgBouncer-Serverparameter ist nur im Bereich Serverparameter sichtbar, wenn der pgbouncer.enabled-Serverparameter auf true festgelegt ist. Andernfalls sind sie absichtlich ausgeblendet.

Parametername BESCHREIBUNG Standard
pgbouncer.default_pool_size Setzen Sie diesen Parameterwert auf die Anzahl der Verbindungen pro Benutzer/Datenbankpaar. 50
pgbouncer.ignore_startup_parameters Geben Sie eine durch Trennzeichen getrennte Liste von Parametern ein, die PgBouncer ignorieren soll. Beispielsweise können Sie den Parameter extra_float_digits durch PgBouncer ignorieren lassen. Einige Parameter sind zulässig, alle anderen lösen einen Fehler aus. Diese Fähigkeit ist erforderlich, um übereifrige Java Database Connectivity (JDBC) zu tolerieren, die extra_float_digits=2 bedingungslos in Startpaketen festgelegen will. Verwenden Sie diese Option, wenn die von Ihnen verwendete Bibliothek Fehler wie pq: unsupported startup parameter: extra_float_digits meldet.
pgbouncer.max_client_conn Legen Sie diesen Parameterwert auf die höchste Anzahl von Clientverbindungen mit PgBouncer fest, die Sie unterstützen möchten. 5.000
pgbouncer.max_prepared_statements Wenn dieser Wert ungleich Null ist, verfolgt PgBouncer Befehle auf Protokollebene, die sich auf benannte vorbereitete Anweisungen beziehen und vom Client im Transaktions- und Anweisungspooling-Modus gesendet werden. 0
pgbouncer.min_pool_size Fügen Sie dem Pool weitere Serververbindungen hinzu, wenn diese Zahl unterschritten wird. 0
pgbouncer.pool_mode Setzen Sie diesen Parameterwert für Transaktions-Pooling auf TRANSACTION (dies ist die empfohlene Einstellung für die meisten Workloads). Transaktion
pgbouncer.query_wait_timeout Abfragen dürfen maximal diese Zeit (in Sekunden) auf die Ausführung warten. Wenn die Abfrage während dieser Zeit keinem Server zugewiesen wurde, wird die Verbindung mit dem Client getrennt. 120
pgbouncer.server_idle_timeout Wenn eine Serververbindung mehr als so viele Sekunden im Leerlauf war, wird sie getrennt. Für 0 ist Timeout deaktiviert. 600
pgbouncer.stats_users Durch Kommata getrennte Liste der Datenbankbenutzer, die sich mit der pgBouncer-Konsole verbinden und schreibgeschützte Abfragen ausführen dürfen.

Weitere Informationen zu PgBouncer-Konfigurationen finden Sie unter pgbouncer.ini-Dokumentation.

Version von PgBouncer

Derzeit ist die Version von PgBouncer, die auf allen unterstützten Hauptversionen der Engine (16, 15, 14, 13, 12, 11) in Azure Database for PostgreSQL Flexible Server eingesetzt wird, 1.22.1.

Vorteile

Mit dem integrierten PgBouncer-Feature mit Azure Database for PostgreSQL – Flexible Server können Sie die folgenden Vorteile erzielen:

  • Komfort der vereinfachten Konfiguration: Da PgBouncer in Azure Database for PostgreSQL – Flexible Server integriert ist, ist keine separate Installation oder komplexe Einrichtung erforderlich. Sie können sie direkt aus den Serverparametern konfigurieren.

  • Zuverlässigkeit eines verwalteten Dienstes: PgBouncer bietet die Vorteile von verwalteten Azure-Diensten. Beispielsweise verwaltet Azure Updates von PgBouncer. Automatische Updates beseitigen die Notwendigkeit manueller Wartung und stellen sicher, dass PgBouncer mit den neuesten Features und Sicherheitspatches auf dem neuesten Stand bleibt.

  • Unterstützung für verschiedene Verbindungstypen: PgBouncer in Azure Database for PostgreSQL – Flexible Server bietet Unterstützung für öffentliche und private Verbindungen. Sie können es verwenden, um Benutzern, abhängig von ihren spezifischen Anforderungen, sichere Verbindungen über private Netzwerke oder eine externe Verbindung zur Verfügung zu stellen.

  • Hohe Verfügbarkeit in Failoverszenarien: Wenn ein Standbyserver während eines Failovers zur primären Rolle heraufgestuft wird, wird PgBouncer nahtlos im neu heraufgestuften Standbymodus neu gestartet. Sie müssen keine Änderungen an der Anwendungsverbindungszeichenfolge vornehmen. Dies hilft die kontinuierliche Verfügbarkeit sicherzustellen und die Unterbrechung des Verbindungspools der Anwendung zu minimieren.

Überwachen von PgBouncer

Metriken

Der Azure Database for PostgreSQL – Flexible Server stellt sechs neue Metriken für die Überwachung von PgBouncer-Verbindungspooling bereit:

Anzeigename Metrik-ID Einheit Beschreibung Dimension Standardmäßig aktiviert
Aktive Clientverbindungen (Vorschau) client_connections_active Anzahl Verbindungen von Clients, die einer Verbindung mit dem flexiblen Server von Azure Database for PostgreSQL-Verbindung zugeordnet sind DatabaseName No
Wartende Clientverbindungen (Vorschau) client_connections_waiting Anzahl Verbindungen von Clients, die auf eine Verbindung mit dem flexiblen Server von Azure Database for PostgreSQL warten, um sie bedienen zu können DatabaseName No
Aktive Serververbindungen (Vorschau) server_connections_active Anzahl Verbindungen mit dem Azure Database for PostgreSQL – Flexible Server, die von einer Clientverbindung verwendet werden DatabaseName No
Serververbindungen im Leerlauf (Vorschau) server_connections_idle Anzahl Verbindungen mit dem Azure Database for PostgreSQL – Flexible Server, die sich im Leerlauf befinden und für die Verarbeitung einer neuen Clientverbindung verfügbar sind DatabaseName No
Gesamtanzahl von Poolverbindungen (Vorschau) total_pooled_connections Anzahl Aktuelle Anzahl von Poolverbindungen DatabaseName No
Anzahl von Verbindungspools (Vorschau) num_pools Anzahl Gesamtanzahl von Verbindungspools DatabaseName No

Weitere Informationen finden Sie unter PgBouncer-Metriken.

Verwaltungskonsole

PgBouncer stellt auch eine interne Datenbank namens pgbouncer bereit. Wenn Sie eine Verbindung mit dieser Datenbank herstellen, können Sie SHOW-Befehle ausführen, die Informationen zum aktuellen Status von PgBouncer bereitstellen.

So stellen Sie die Verbindung mit der pgbouncer-Datenbank her:

  1. Legen Sie den pgBouncer.stats_users-Parameter auf den Namen eines vorhandenen Benutzers fest (z. B myUser) und wenden Sie die Änderungen an.

  2. Stellen Sie eine Verbindung mit der pgbouncer-Datenbank als dieser Benutzer her und legen Sie den Port auf 6432 fest:

    psql "host=myPgServer.postgres.database.azure.com port=6432 dbname=pgbouncer user=myUser password=myPassword sslmode=require"

Nachdem Sie eine Verbindung mit der Datenbank hergestellt haben, verwenden Sie SHOW-Befehle zum Anzeigen von PgBouncer-Statistiken:

  • SHOW HELP: Listet alle verfügbaren SHOW-Befehle auf.
  • SHOW POOLS: Anzeigen der Anzahl von Verbindungen in jedem Zustand für jeden Pool.
  • SHOW DATABASES: Anzeigen der aktuell angewendeten Verbindungsgrenzwerte für jede Datenbank.
  • SHOW STATS: Anzeigen von Statistiken zu Anforderungen und Datenverkehr für jede Datenbank.

Weitere Informationen zu den SHOW-Befehlen von PgBouncer finden Sie in der Verwaltungskonsole.

Umschalten Ihrer Anwendung auf die Verwendung von PgBouncer

Um PgBouncer zu verwenden, führen Sie die folgenden Schritte aus:

  1. Stellen Sie eine Verbindung mit Ihrem Datenbankserver her, aber verwenden Sie nicht den regulären Port 5432, sondern Port 6432. Stellen Sie sicher, dass diese Verbindung funktioniert.

    psql "host=myPgServer.postgres.database.azure.com port=6432 dbname=postgres user=myUser password=myPassword sslmode=require"

  2. Testen Sie Ihre Anwendung in einer QA-Umgebung gegen PgBouncer, um sicherzustellen, dass Sie keine Kompatibilitätsprobleme haben. Das PgBouncer-Projekt stellt eine Kompatibilitätsmatrix bereit, und den meisten Benutzern wird Transaktionspooling empfohlen.

  3. Ändern Sie Ihre Produktionsanwendung, um eine Verbindung mit Port 6432 anstelle von 5432 herzustellen. Überwachen Sie alle anwendungsseitigen Fehler, die auf Kompatibilitätsprobleme hinweisen können.

PgBouncer in zonenredundanter Hochverfügbarkeit

In zonenredundanten, hochverfügbaren (HA)-Servern führt der primäre Server PgBouncer aus. Sie können sich über Port 6432 mit dem PgBouncer des Primärservers verbinden. Nach einem Failover wird der PgBouncer auf dem neu heraufgestuften Standby-Server, welcher der neue primäre Server ist, neu gestartet. So bleibt die Verbindungszeichenfolge Ihrer Anwendung nach dem Failover gleich.

Verwendung von PgBouncer mit anderen Verbindungspools

In einigen Fällen verfügen Sie möglicherweise bereits über einen anwendungsseitigen Verbindungspool oder haben PgBouncer auf Ihrer Anwendungsseite eingerichtet (z. B. ein Azure Kubernetes Service-Sidecar). In diesen Fällen kann das integrierte PgBouncer-Feature weiterhin nützlich sein, da es die Vorteile der Leerlaufverbindungsskalierung bietet.

Die Verwendung eines anwendungsseitigen Pools zusammen mit PgBouncer auf dem Datenbankserver kann von Vorteil sein. Hier bietet der anwendungsseitige Pool den Vorteil einer reduzierten anfänglichen Verbindungslatenz (da der Roundtrip zum Initialisieren der Verbindung viel schneller ist), und der datenbankseitige PgBouncer ermöglicht die Skalierung von Verbindungen im Leerlauf.

Begrenzungen

  • Das PgBouncer-Feature wird derzeit nicht mit Burstable Server Compute Tier unterstützt. Wenn Sie die Berechnungsschicht von "General Purpose" oder „arbeitsspeicheroptimiert“ auf „burstfähig“ ändern, verlieren Sie die integrierte PgBouncer-Funktion.

  • Wann immer der Server während der Skalierungsvorgänge, des HA-Failovers oder eines Neustarts neu gestartet wird, werden PgBouncer und die VM ebenfalls neu gestartet. Anschließend müssen Sie die vorhandenen Verbindungen erneut einrichten.

  • Das Portal zeigt nicht alle PgBouncer-Parameter an. Nachdem Sie PgBouncer aktiviert und die Parameter gespeichert haben, müssen Sie den Bereich Serverparameter schließen (z. B. Übersicht auswählen) und dann zum Bereich Serverparameter zurückkehren.

  • Sie können Anweisungspoolmodi nicht gemeinsam mit vorbereiteten Anweisungen verwenden. In der aktuellen Version von PgBouncer wurde Unterstützung für vorbereitete Anweisungen im Transaktionsmodus hinzugefügt. Diese Unterstützung kann über den Parameter max_prepared_statements aktiviert und konfiguriert werden. Wenn Sie diesem Parameter einen höheren Wert als den Standardwert von 0 zuweisen, wird die Unterstützung für vorbereitete Anweisungen aktiviert. Diese Unterstützung gilt nur für vorbereitete Anweisungen auf Protokollebene. Für die meisten Programmiersprachen bedeutet dies, dass wir auf dem Client die libpq-Funktion PQprepare verwenden, die Befehle auf Protokollebene sendet, die PgBouncer abfangen kann, anstatt einen dynamischen SQL-Befehl wie PREPARE proc AS zu verwenden, der Text sendet, den PgBouncer nicht korrekt interpretieren kann. Weitere Einschränkungen des gewählten Poolmodus finden Sie in der PgBouncer-Dokumentation.

  • Wenn PgBouncer als Feature bereitgestellt wird, wird es zu einem potenziellen Single Point of Failure. Wenn die PgBouncer-Funktion ausfällt, kann dies den gesamten Datenbankverbindungspool unterbrechen und zu Ausfallzeiten für die Anwendung führen. Um einen Single Point of Failure zu vermeiden, können Sie mehrere PgBouncer-Instanzen hinter einem Lastenausgleich für Hochverfügbarkeit auf der Azure VM einrichten.

  • Tokengrößeneinschränkung mit AAD-Authentifizierung: Benutzer, die sehr viele Gruppenmitgliedschaften besitzen, können aufgrund einer Tokengrößeneinschränkung keine Verbindung über PgBouncer herstellen. Anwendungen, Dienste und Benutzer mit einer kleinen Anzahl von Gruppen funktionieren.

  • PgBouncer ist eine einfache Anwendung, die eine Singlethread-Architektur verwendet. Dieses Design eignet sich hervorragend für die meisten Anwendungsworkloads. In Anwendungen, die eine große Anzahl von kurzlebigen Verbindungen erstellen, kann sich dieses Design jedoch auf die Leistung von pgBouncer auswirken und ihre Fähigkeit zum Skalieren Ihrer Anwendung einschränken. Möglicherweise müssen Sie einen der folgenden Ansätze ausprobieren:

    • Verteilen Sie die Verbindungslast über mehrere PgBouncer-Instanzen auf Azure-VMs.
    • Erwägen Sie alternative Lösungen, einschließlich Multithread-Lösungen wie PgCat, auf Azure-VMs.

Wichtig

Der Parameter pgbouncer.client_tls_sslmode für das integrierte PgBouncer-Feature ist in Azure Database for PostgreSQL – Flexible Server veraltet.

Wenn TLS\SSL für Verbindungen mit Azure Database for PostgreSQL – Flexible Server erzwungen wird, indem der Serverparameter require_secure_transport auf ON festgelegt wird, wird TLS\SSL für Verbindungen mit dem integrierten PgBouncer-Feature automatisch erzwungen. Diese Einstellung ist standardmäßig aktiviert, wenn Sie eine neue Azure Database for PostgreSQL – Flexible Serverinstanz erstellen und das integrierte PgBouncer-Feature aktivieren. Weitere Informationen finden Sie unter Übersicht über den Netzwerkbetrieb bei Azure Database for PostgreSQL – Flexible Server mit privatem Zugriff.

Für Kunden, die vereinfachte Verwaltung, integrierte hohe Verfügbarkeit, einfache Konnektivität mit containerisierten Anwendungen und die Möglichkeit zur Verwendung der am häufigsten verwendeten Konfigurationsparameter benötigen, ist das integrierte PgBouncer-Feature eine gute Wahl. Für Kunden, die Multithreadskalierbarkeit, vollständige Kontrolle über alle Parameter und eine Debugerfahrung wünschen, kann das Einrichten von PgBouncer auf Azure-VMs eine Alternative sein.

Nächste Schritte