Strategie für das Verbindungspooling für Azure Database for PostgreSQL – Flexibler Server mit PgBouncer

Artikel
08/15/2024

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

Strategischer Leitfaden für die Auswahl des Verfahrens für das Verbindungspooling für Azure Database for PostgreSQL – Flexibler Server.

Einführung

Bei Verwendung von Azure Database for PostgreSQL – Flexibler Server erfordert das Herstellen einer Verbindung mit der Datenbank das Erstellen eines Kommunikationskanals zwischen der Clientanwendung und dem Server. Dieser Kanal ist für die Verwaltung von Daten, das Ausführen von Abfragen und das Initiieren von Transaktionen verantwortlich. Sobald die Verbindung hergestellt wurde, kann die Clientanwendung Befehle an den Server senden und Antworten empfangen. Das Erstellen einer neuen Verbindung für jeden Vorgang kann jedoch Leistungsprobleme für unternehmenskritische Anwendungen verursachen. Jedes Mal, wenn eine neue Verbindung erstellt wird, startet Azure Database for PostgreSQL – Flexibler Server einen neuen Prozess mithilfe des postmaster-Prozesses, der mehr Ressourcen verbraucht.

Um dieses Problem zu umgehen, wird das Verbindungspooling verwendet, um einen Cache mit Verbindungen zu erstellen, die in Azure Database for PostgreSQL – Flexibler Server wiederverwendet werden können. Wenn eine Anwendung oder ein Client eine Verbindung anfordert, wird sie aus dem Verbindungspool erstellt. Nach Abschluss der Sitzung oder Transaktion wird die Verbindung zur Wiederverwendung an den Pool zurückgegeben. Durch die Wiederverwendung von Verbindungen wird die Ressourcenauslastung reduziert, und die Leistung wird verbessert.

Diagramm für Verbindungspoolingmuster.

Obwohl es verschiedene Tools für Verbindungspooling gibt, werden in diesem Abschnitt verschiedene Strategien zur Verwendung von Verbindungspooling mit PgBouncer erläutert.

Was ist PgBouncer?

PgBouncer ist ein effizienter Verbindungspooler, der für PostgreSQL entwickelt wurde und den Vorteil bietet, die Verarbeitungszeit zu reduzieren und die Ressourcennutzung beim Verwalten mehrerer Clientverbindungen mit einer oder mehreren Datenbanken zu optimieren. PgBouncer umfasst drei verschiedene Pooling-Modi für die Verbindungsrotation:

Sitzungspooling: Diese Methode weist der Clientanwendung für die gesamte Dauer der Clientverbindung eine Serververbindung zu. Nach dem Trennen der Clientanwendung gibt PgBouncer die Serververbindung sofort wieder an den Pool zurück. Das Sitzungspooling ist der Standardmodus in Open Source PgBouncer. Siehe PgBouncer-Konfiguration
Transaktionspooling: Beim Transaktionspooling wird während einer Transaktion eine Serververbindung für die Clientanwendung dediziert. Sobald die Transaktion erfolgreich abgeschlossen wurde, gibt PgBouncer die Serververbindung intelligent frei und stellt sie innerhalb des Pools wieder zur Verfügung. Das Transaktionspooling ist der Standardmodus im integrierten PgBouncer von Azure Database for PostgreSQL – Flexibler Server, das keine vorbereiteten Transaktionen unterstützt.
Anweisungspooling: Beim Anweisungspooling wird der Clientanwendung für jede einzelne Anweisung eine Serververbindung zugeordnet. Nach Abschluss der Anweisung wird die Serververbindung umgehend an den Verbindungspool zurückgegeben. Beachten Sie, dass Transaktionen mit mehreren Anweisungen in diesem Modus nicht unterstützt werden.

Die effektive Nutzung von PgBouncer kann in drei verschiedene Verwendungsmuster unterteilt werden.

PgBouncer- und Anwendungscolocation-Bereitstellung
Anwendungsunabhängige zentralisierte PgBouncer-Bereitstellungen
Integrierte PgBouncer- und Datenbankbereitstellung

Jedes dieser Muster hat seine eigenen Vor- und Nachteile.

1. PgBouncer- und Anwendungscolocation-Bereitstellung

Wenn Sie diesen Ansatz verwenden, wird PgBouncer auf demselben Server bereitgestellt, auf dem Ihre Anwendung gehostet wird. Die Anwendung und PgBouncer können entweder auf herkömmlichen VMs oder in einer auf Microservices basierenden Architektur bereitgestellt werden, wie hervorgehoben:

I. PgBouncer, bereitgestellt auf Anwendungs-VM

Wenn Ihre Anwendung auf einer Azure-VM ausgeführt wird, können Sie PgBouncer auf derselben VM einrichten. Befolgen Sie die Anweisungen unter dem folgenden Link, um PgBouncer als Verbindungspoolproxy mit Azure Database for PostgreSQL – Flexibler Server zu installieren und zu konfigurieren.

Diagramm für App-Colocation auf VM.

Die Bereitstellung von PgBouncer auf einem Anwendungsserver kann mehrere Vorteile bieten, insbesondere beim Arbeiten mit Datenbanken in Azure Database for PostgreSQL – Flexibler Server. Einige der Vorteile und Einschränkungen dieser Bereitstellungsmethode sind:

Vorteile:

Reduzierte Latenz: Durch die Bereitstellung von PgBouncer auf derselben Anwendungs-VM ist die Kommunikation zwischen der primären Anwendung und dem Verbindungspooler aufgrund ihrer Nähe effizient. Die Bereitstellung von PgBouncer auf der Anwendungs-VM minimiert die Latenz und sorgt für reibungslose und schnelle Interaktionen.
Verbesserte Sicherheit: PgBouncer kann als sicherer Vermittler zwischen der Anwendung und der Datenbank fungieren, wodurch eine zusätzliche Sicherheitsschicht vorhanden ist. Es kann Authentifizierung und Verschlüsselung erzwingen und so sicherstellen, dass nur autorisierte Clients auf die Datenbank zugreifen können.

Insgesamt bietet die Bereitstellung von PgBouncer auf einem Anwendungsserver einen effizienteren, sichereren und skalierbareren Ansatz für die Verwaltung von Verbindungen mit Datenbanken in Azure Database for PostgreSQL – Flexibler Server, wodurch die Leistung und Zuverlässigkeit der Anwendung verbessert wird.

Einschränkungen:

Single Point of Failure: Wenn PgBouncer als einzelne Instanz auf dem Anwendungsserver bereitgestellt wird, wird es zu einem potenziellen Single Point of Failure. Wenn die PgBouncer-Instanz ausfällt, kann dies den gesamten Datenbankverbindungspool unterbrechen, was zu Ausfallzeiten für die Anwendung führt. Um Single Point of Failure zu minimieren, können Sie mehrere PgBouncer-Instanzen hinter einem Lastenausgleich für Hochverfügbarkeit einrichten.
Eingeschränkte Skalierbarkeit: Die Skalierbarkeit von PgBouncer hängt von der Kapazität des Servers ab, auf dem er bereitgestellt wird. Wenn der Anwendungsserver seine Verbindungsgrenze erreicht, kann PgBouncer zu einem Engpass werden, der die Möglichkeit zum Skalieren der Anwendung einschränkt. Möglicherweise müssen Sie die Verbindungslast auf mehrere PgBouncer-Instanzen verteilen oder alternative Lösungen wie Verbindungspooling auf Anwendungsebene in Betracht ziehen.
Konfigurationskomplexität: Das Konfigurieren und Optimieren von PgBouncer kann komplex sein, insbesondere wenn Faktoren wie Verbindungsgrenzwerte, Pooldimensionierung und Lastenausgleich berücksichtigt werden. Administratoren müssen die PgBouncer-Konfiguration sorgfältig an die Anforderungen der Anwendung anpassen und eine optimale Leistung und Stabilität gewährleisten.

Es ist wichtig, diese Einschränkungen gegen die Vorteile abzuwägen und zu bewerten, ob PgBouncer die richtige Wahl für Ihre spezifische Anwendungs- und Datenbankeinrichtung ist.

II. PgBouncer als AKS Sidecar bereitgestellt

Es ist möglich, PgBouncer als Sidecar-Container zu verwenden, wenn Ihre Anwendung containerisiert ist und auf Azure Kubernetes Service (AKS), Azure Container Instance (ACI), Azure Container Apps (ACA) oder Azure Red Hat OpenShift (ARO) ausgeführt wird. Das Sidecar-Muster bezieht sich auf das Konzept eines Beiwagens (Sidecars), der an einem Motorrad befestigt ist: Ein Hilfscontainer, der als Sidecar-Container bezeichnet wird, ist an eine übergeordnete Anwendung angefügt. Dieses Muster bereichert die übergeordnete Anwendung, indem es ihre Funktionen erweitert und zusätzliche Unterstützung bietet.

Das Sidecar-Muster wird in der Regel verwendet, wenn Container als atomische Containergruppe geplant werden. Die Bereitstellung von PgBouncer in einem AKS-Sidecar verknüpft den Anwendungs- und Sidecar-Lebenszyklus eng und teilt Ressourcen wie Hostname und Netzwerk, um Ressourcen effizient zu nutzen. Das PgBouncer-Sidecar arbeitet zusammen mit dem Anwendungscontainer innerhalb desselben Pods in Azure Kubernetes Service (AKS) mit 1:1-Zuordnung und dient als Verbindungspoolingproxy für Azure Database for PostgreSQL – Flexibler Server.

Das Sidecar-Muster wird in der Regel verwendet, wenn Container als atomische Containergruppe geplant werden. Das Sidecarmuster bindet den Anwendungs- und Sidecar-Lebenszyklus stark und verfügt über freigegebene Ressourcen wie Hostname und Netzwerk. Mit diesem Setup optimiert PgBouncer die Verbindungsverwaltung und vereinfacht eine effiziente Kommunikation zwischen der Anwendung und der Instanz von Azure Database for PostgreSQL – Flexibler Server.

Microsoft hat ein Image für den PgBouncer-Sidecar-Proxy in der Microsoft-Containerregistrierung veröffentlicht.

Weitere Informationen finden Sie hier.

Diagramm für App-Colocation auf Sidecar.

Einige der Vorteile und Einschränkungen dieser Bereitstellungsmethode sind:

Vorteile:

Reduzierte Latenz: Durch die Bereitstellung von PgBouncer als AKS-Sidecar ist die Kommunikation zwischen der primären Anwendung und dem Verbindungspooler aufgrund ihrer Nähe nahtlos und effizient. Die Bereitstellung von PgBouncer als AKS-Sidecar minimiert die Latenz und sorgt für reibungslose und schnelle Interaktionen.
Vereinfachte Verwaltung und Bereitstellung: Die enge Kopplung von PgBouncer mit dem Anwendungscontainer vereinfacht den Verwaltungs- und Bereitstellungsprozess. Beide Komponenten sind eng integriert, was eine einfachere Verwaltung und nahtlose Koordination ermöglicht.
Hochverfügbarkeit und Verbindungsresilienz: Wenn ein Anwendungscontainer ausfällt oder neu gestartet wird, folgt der PgBouncer-Sidecar-Container eng, um Hochverfügbarkeit zu gewährleisten. Dieses Setup garantiert die Verbindungsresilienz und behält auch bei Failovern eine vorhersagbare Leistung bei, was zu einem zuverlässigen und robusten System beiträgt.

Wenn Sie PgBouncer als AKS-Sidecar betrachten, können Sie diese Vorteile nutzen, um die Leistung Ihrer Anwendung zu verbessern, die Verwaltung zu optimieren und die kontinuierliche Verfügbarkeit des Verbindungspoolers sicherzustellen.

Einschränkungen:

Probleme mit der Verbindungsleistung: Bei umfangreichen Anwendungen, die Tausende von Pods verwenden, die jeweils Sidecar-PgBouncer ausführen, können potenzielle Herausforderungen im Zusammenhang mit der Erschöpfung der Datenbankverbindung auftreten. Diese Situation kann zu Leistungseinbußen und Dienstunterbrechungen führen. Durch die Bereitstellung eines Sidecar-PgBouncer für jeden Pod wird die Anzahl gleichzeitiger Verbindungen mit dem Datenbankserver erhöht, wodurch die Kapazität überschritten werden kann. Daher kann die Datenbank Probleme mit der Verarbeitung der hohen Anzahl eingehender Verbindungen haben, was zu Leistungsproblemen führen kann, z. B. zu erhöhten Antwortzeiten oder sogar Dienstausfällen.
Komplexe Bereitstellung: Die Verwendung des Sidecar-Musters führt zu einer Komplexität des Bereitstellungsprozesses, da zwei Container innerhalb desselben Pods ausgeführt werden. Dies kann möglicherweise die Problembehandlung und das Debuggen von Aktivitäten erschweren, was zusätzlichen Aufwand erfordert, um Probleme zu identifizieren und zu beheben.
Skalierungsanforderungen: Es ist wichtig zu beachten, dass das Sidecar-Muster möglicherweise nicht die ideale Wahl für Anwendungen ist, die eine hohe Skalierbarkeit erfordern. Die Einbindung eines Sidecar-Containers kann zu mehr Ressourcenanforderungen führen, wodurch möglicherweise die Anzahl von Pods begrenzt wird, die effektiv erstellt und verwaltet werden können.

Wenn Sie dieses Sidecar-Muster in Erwägung ziehen, müssen Sie die Kompromisse zwischen der Komplexität der Bereitstellung und den Anforderungen an die Skalierbarkeit sorgfältig abwägen, um den für Ihr spezifisches Anwendungsszenario am besten geeigneten Ansatz zu ermitteln.

2. Anwendungsunabhängige zentralisierte PgBouncer-Bereitstellung

Bei Verwendung dieses Ansatzes wird PgBouncer unabhängig von der Anwendung als zentralisierter Dienst bereitgestellt. Der PgBouncer-Dienst kann entweder auf herkömmlichen virtuellen Computern oder in einer microservicesbasierten Architektur bereitgestellt werden, wie hervorgehoben:

I. PgBouncer auf Ubuntu-VM hinter Azure Load Balancer

Der PgBouncer-Verbindungsproxy wird zwischen der Anwendungs- und Datenbankebene hinter einer Azure Load Balancer-Instanz eingerichtet, wie in der Abbildung dargestellt. In diesem Muster werden mehrere PgBouncer-Instanzen hinter einem Lastenausgleichsmodul als Dienst bereitgestellt, um einen Single Point of Failure zu vermeiden. Dieses Muster eignet sich auch in Szenarien, in denen die Anwendung in einem verwalteten Dienst wie Azure App Services oder Azure Functions ausgeführt wird und eine Verbindung mit dem PgBouncer-Dienst für eine einfache Integration in Ihre vorhandene Infrastruktur hergestellt wird.

Weitere Informationen finden Sie unter dem Link zum Installieren und Einrichten des PgBouncer-Verbindungspoolingproxys mit Azure Database for PostgreSQL – Flexibler Server.

Diagramm für App-Colocation auf VM mit Load Balancer.

Einige der Vorteile und Einschränkungen dieser Bereitstellungsmethode sind:

Vorteile:

Entfernen des Single Point of Failure: Die Anwendungskonnektivität wird möglicherweise nicht durch den Ausfall einer einzelnen PgBouncer-VM beeinträchtigt, da sich mehrere PgBouncer-Instanzen hinter Azure Load Balancer befinden.
Nahtlose Integration mit verwalteten Diensten: Wenn Ihre Anwendung auf einer verwalteten Dienstplattform wie Azure-App Services oder Azure Functions gehostet wird, ermöglicht die Bereitstellung von PgBouncer auf einem virtuellen Computer eine einfache Integration in Ihre vorhandene Infrastruktur.
Vereinfachte Einrichtung auf einem virtuellen Azure-Computer: Wenn Sie Ihre Anwendung bereits auf einer Azure-VM ausführen, ist das Einrichten von PgBouncer auf derselben VM einfach. Durch die Bereitstellung von PgBouncer auf einem virtuellen Computer wird sichergestellt, dass PgBouncer in unmittelbarer Nähe zu Ihrer Anwendung bereitgestellt wird, wodurch die Netzwerklatenz minimiert und die Leistung maximiert wird.
Nicht-intrusive Konfiguration: Wenn Sie PgBouncer auf einer VM bereitstellen, können Sie das Ändern von Serverparametern in Azure Database for PostgreSQL – Flexibler Server vermeiden. Dies ist nützlich, wenn Sie PgBouncer für eine Instanz von Azure Database for PostgreSQL – Flexibler Server konfigurieren möchten. Wenn Sie beispielsweise den SSLMODE-Parameter in Azure Database for PostgreSQL – Flexibler Server in „required“ (erforderlich) ändern, können bestimmte Anwendungen Fehler verursachen, wenn sie die Einstellung „SSLMODE=FALSE“ benötigen. Durch die Bereitstellung von PgBouncer auf einem separaten virtuellen Computer können Sie die Standardserverkonfiguration beibehalten und gleichzeitig die Vorteile von PgBouncer nutzen.

Wenn Sie diese Vorteile berücksichtigen, bietet die Bereitstellung von PgBouncer auf einem virtuellen Computer eine praktische und effiziente Lösung zur Verbesserung der Leistung und Kompatibilität Ihrer Anwendung, die in der Azure-Infrastruktur ausgeführt wird.

Einschränkungen:

Verwaltungsaufwand: Da PgBouncer auf einem virtuellen Computer installiert wird, kann der Aufwand bei der Verwaltung mehrerer Konfigurationsdateien steigen. Dies erschwert die Bewältigung von Versionsupgrades, neuen Releases und Produktupdates.
Featureparität: Wenn Sie von herkömmlichem PostgreSQL zu Azure Database for PostgreSQL – Flexibler Server migrieren und PgBouncer verwenden, können einige Featurelücken entstehen. Ein Beispiel ist die fehlende MD5-Unterstützung in Azure Database for PostgreSQL – Flexibler Server.

II. Zentralisierte PgBouncer-Bereitstellung als Dienst in AKS

Wenn Sie mit hoch skalierbaren und großen containerisierten Bereitstellungen auf Azure Kubernetes Service (AKS) arbeiten, die aus Hunderten von Pods bestehen, oder in Situationen, in denen mehrere Anwendungen eine Verbindung mit einer freigegebenen Datenbank herstellen müssen, kann PgBouncer als eigenständiger Dienst und nicht als Sidecar-Container verwendet werden.

Durch die Verwendung von PgBouncer als separaten Dienst können Sie das Verbindungspooling für Ihre Anwendungen in größerem Umfang effizient verwalten und verarbeiten. Dieser Ansatz ermöglicht die Zentralisierung der Verbindungspoolfunktion, sodass mehrere Anwendungen eine Verbindung mit derselben Datenbankressource herstellen können, während gleichzeitig optimale Leistung und Ressourcennutzung beibehalten werden.

Das in der Microsoft-Containerregistrierung veröffentlichte PgBouncer-Sidecar-Proxyimage kann zum Erstellen und Bereitstellen eines Diensts verwendet werden.

Diagramm für PgBouncer als Dienst in AKS.

Einige der Vorteile und Einschränkungen dieser Bereitstellungsmethode sind:

Vorteile:

Verbesserte Zuverlässigkeit: Die Bereitstellung von PgBouncer als eigenständiger Dienst ermöglicht die Konfiguration auf hochverfügbare Weise. Dies verbessert die allgemeine Zuverlässigkeit der Verbindungspoolinfrastruktur und stellt auch bei Ausfällen oder Unterbrechungen eine kontinuierliche Verfügbarkeit sicher.
Optimale Ressourcennutzung: Wenn Ihre Anwendung oder der Datenbankserver über begrenzte Ressourcen verfügt, kann die Entscheidung für einen dedizierten Computer für die Ausführung des PgBouncer-Diensts von Vorteil sein. Durch die Bereitstellung von PgBouncer auf einem Computer mit umfangreichen Ressourcen können Sie eine optimale Leistung sicherstellen und Ressourcenkonflikte verhindern.
Zentrale Verbindungsverwaltung: Wenn eine zentralisierte Verwaltung von Datenbankverbindungen erforderlich ist, bietet ein eigenständiger PgBouncer-Dienst einen optimierten Ansatz. Durch die Konsolidierung von Verbindungsverwaltungsaufgaben in einem zentralisierten Dienst können Sie Datenbankverbindungen über mehrere Anwendungen hinweg effektiv überwachen und steuern, wodurch die Verwaltung vereinfacht und Konsistenz sichergestellt wird.

Wenn Sie PgBouncer als eigenständigen Dienst in AKS betrachten, können Sie diese Vorteile nutzen, um eine verbesserte Zuverlässigkeit, Ressourceneffizienz und eine zentralisierte Verwaltung von Datenbankverbindungen zu erzielen.

Einschränkungen:

Erhöhte N/W-Latenz: Bei der Bereitstellung von PgBouncer als eigenständiger Dienst ist es wichtig, die mögliche Einführung von mehr Latenz zu berücksichtigen. Diese ist darauf zurückzuführen, dass Verbindungen zwischen der Anwendung und dem PgBouncer-Dienst über das Netzwerk übergeben werden müssen. Es ist von entscheidender Bedeutung, die Latenzanforderungen Ihrer Anwendung zu bewerten und die Kompromisse zwischen der zentralisierten Verbindungsverwaltung und potenziellen Latenzproblemen abzuwägen.

Während PgBouncer, der als eigenständiger Dienst ausgeführt wird, Vorteile wie die zentralisierte Verwaltung und Ressourcenoptimierung bietet, ist es wichtig, die Auswirkungen der potenziellen Latenz auf die Leistung Ihrer Anwendung zu bewerten, um sicherzustellen, dass sie ihren spezifischen Anforderungen entspricht.

3. Integrierter PgBouncer in 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. Dies wird als optionaler Dienst angeboten, der pro Datenbankserver aktiviert werden kann. PgBouncer wird auf derselben VM wie die Instanz von Azure Database for PostgreSQL – Flexibler Server ausgeführt. Wenn die Anzahl der Verbindungen einige Hundert oder Tausend überschreitet, treten bei Azure Database for PostgreSQL – Flexibler Server möglicherweise Ressourcenengpässe auf. In solchen Fällen kann der integrierte PgBouncer einen erheblichen Vorteil bieten, indem er die Verwaltung von ungenutzten und kurzlebigen Verbindungen auf dem Datenbankserver verbessert.

Weitere Informationen zum Aktivieren und Einrichten des PgBouncer-Verbindungspoolings in Azure Database for PostgreSQL – Flexibler Server finden Sie unter dem Link.

Einige der Vorteile und Einschränkungen dieser Bereitstellungsmethode sind:

Vorteile:

Nahtlose Konfiguration: Für den integrierten PgBouncer in Azure Database for PostgreSQL – Flexibler Server ist es nicht erforderlich, eine separate Installation oder ein komplexes Setup durchzuführen. Sie kann einfach direkt aus den Serverparametern konfiguriert werden, um eine problemlose Erfahrung zu gewährleisten.
Vorteil des verwalteten Diensts: Da es sich um einen verwalteten Dienst handelt, können Benutzer die Vorteile anderer verwalteter Azure-Dienste nutzen. Dies umfasst automatische Updates, wodurch die Notwendigkeit manueller Wartung entfällt und sicher gestellt wird, dass PgBouncer mit den neuesten Features und Sicherheitspatches auf dem neuesten Stand bleibt.
Unterstützung für öffentliche und private Verbindung: Der integrierte PgBouncer in Azure Database for PostgreSQL – Flexibler Server bietet Unterstützung für öffentliche und private Verbindungen. Diese ermöglicht es Benutzern, abhängig von ihren spezifischen Anforderungen sichere Verbindungen über private Netzwerke oder eine externe Verbindung herzustellen.
Hochverfügbarkeit (HA): Im Falle eines Failovers, bei dem ein Standbyserver zur primären Rolle heraufgestuft wird, wird PgBouncer nahtlos im neu heraufgestuften Standby neu gestartet, ohne dass Änderungen an der Anwendungsverbindungszeichenfolge erforderlich sind. Dadurch wird die kontinuierliche Verfügbarkeit sichergestellt und die Unterbrechung der Anwendung minimiert.
Kosteneffizient: Dieser Ansatz ist kosteneffizient, da die Benutzer:innen nicht für zusätzliche Berechnungen wie VMs oder Container bezahlen müssen, obwohl sie Auswirkungen auf die CPU-Auslastung haben, da es sich um einen anderen Prozess handelt, der auf demselben Computer ausgeführt wird.

Mit dem in Azure Database for PostgreSQL – Flexibler Server integrierten PgBouncer können Benutzer:innen den Komfort einer vereinfachten Konfiguration, die Zuverlässigkeit eines verwalteten Diensts, die Unterstützung verschiedener Poolingmodi und nahtlose Hochverfügbarkeit bei einem Failover genießen.

Einschränkungen:

Keine Unterstützung für Burstfähigkeit: PgBouncer wird derzeit nicht im Servercomputetarif „Burstfähig“ unterstützt. Wenn Sie die Berechnungsschicht von „Universell“ oder „arbeitsspeicheroptimiert“ auf „burstfähig“ ändern, verlieren Sie die PgBouncer-Funktion.
Wiederherstellen der Verbindungen nach Neustarts: Immer wenn der Server während Skalierungsvorgängen, HA-Failover oder einem Neustart neu gestartet wird, wird auch der PgBouncer zusammen mit der virtuellen Maschine des Servers neu gestartet. Daher müssen vorhandene Verbindungen erneut hergestellt werden.

Wir haben verschiedene Möglichkeiten zur Implementierung von PgBouncer erläutert, und die Tabelle fasst zusammen, für welche Bereitstellungsmethode Sie sich entscheiden sollten: