PostgreSQL
 sql >> Datenbank >  >> RDS >> PostgreSQL

PostgreSQL-Verbindungspooling:Teil 2 – PgBouncer

Wenn es um Verbindungspooling in der PostgreSQL-Welt geht, ist PgBouncer wahrscheinlich die beliebteste Option. Es ist ein sehr einfaches Dienstprogramm, das genau eines tut – es sitzt zwischen der Datenbank und den Clients und spricht das PostgreSQL-Protokoll, indem es einen PostgreSQL-Server emuliert. Ein Client verbindet sich mit PgBouncer mit genau derselben Syntax, die er verwenden würde, wenn er sich direkt mit PostgreSQL verbindet – PgBouncer ist im Wesentlichen unsichtbar.

PgBouncer wird von fast allen PostgreSQL-DBaaS-Anbietern unterstützt und in der Community weit verbreitet. In diesem Blogbeitrag erklären wir, wie PgBouncer funktioniert, die Vor- und Nachteile seiner Verwendung und wie man den Connection Pooler einrichtet. Wenn Sie mehr über Connection Pooling im Allgemeinen erfahren möchten oder sich fragen, ob es für Ihre Bereitstellung geeignet ist, lesen Sie unseren PostgreSQL Connection Pooling:Part 1 – Pros &Cons post.

PostgreSQL Connection Pooling-Reihe

  • Teil 1 – Vor- und Nachteile
  • Teil 2 – PgBouncer
  • Teil 3 – Pgpool-II
  • Teil 4 – PgBouncer vs. Pgpool-II

Wie funktioniert PgBouncer?

Wenn PgBouncer eine Client-Verbindung empfängt, führt es zunächst eine Authentifizierung im Namen des PostgreSQL-Servers durch. PgBouncer unterstützt alle Authentifizierungsmechanismen, die der PostgreSQL-Server unterstützt, einschließlich einer hostbasierten Zugriffskonfiguration (Hinweis:Wir können Replikationsverbindungen nicht über PgBouncer leiten). Wenn ein Passwort angegeben wird, kann die Authentifizierung auf zwei Arten erfolgen:

  1. PgBouncer überprüft zuerst die Datei userslist.txt – diese Datei spezifiziert einen Satz von Tupeln (Benutzername, md5-verschlüsselte Passwörter). Wenn der Benutzername in dieser Datei vorhanden ist, wird das Passwort mit dem angegebenen Wert abgeglichen. Es wird keine Verbindung zum PostgreSQL-Server hergestellt.
  2. Wenn Passthrough-Authentifizierung eingerichtet ist und der Benutzer nicht in der Datei userslist.txt gefunden wird, sucht PgBouncer nach einer auth_query. Es verbindet sich mit PostgreSQL als vordefinierter Benutzer (dessen Passwort in der Datei userslist.txt vorhanden sein muss) und führt die Authentifizierungsabfrage aus, um das Passwort des Benutzers zu finden und mit dem angegebenen Wert abzugleichen.

Sobald die Authentifizierung erfolgreich war:

  1. PgBouncer sucht nach einer zwischengespeicherten Verbindung mit derselben Kombination aus Benutzername und Datenbank.
  2. Wenn eine zwischengespeicherte Verbindung gefunden wird, wird die Verbindung an den Client zurückgegeben.
  3. Wenn eine zwischengespeicherte Verbindung nicht gefunden wird, wird eine neue Verbindung erstellt, vorausgesetzt, das Erstellen einer neuen Verbindung tut dies nicht:
    • Erhöhen Sie die Anzahl der Verbindungen zu> pool_size
    • Erhöhen Sie die Anzahl der Verbindungen vom Client auf> max_client_connections
    • Erhöhen Sie die Anzahl der Verbindungen zur Datenbank auf> max_db_connections
    • Erhöhen Sie die Anzahl der Verbindungen vom Benutzer zu> max_user_connections
  4. Alle diese Werte können in den PgBouncer-Einstellungen definiert werden.
  5. Wenn das Erstellen einer neuen Verbindung gegen eine der Einstellungen verstoßen würde, stellt PgBouncer die Verbindung in die Warteschlange, bis eine neue erstellt werden kann, es sei denn, sie verletzt die Einschränkung max_client_connections.
    Hinweis – Das Timing der Schritte nach der Authentifizierung unterscheidet sich geringfügig je nach PgBouncer-Modus. Im Transaktions- oder Anweisungs-Pooling-Modus werden die Nachauthentifizierungsschritte nur ausgeführt, wenn der Client mit der Ausführung einer Transaktion/Anweisung beginnt. Wir diskutieren weiter unten mehr über die Pooling-Modi.
  6. Wenn es gegen die Einschränkung max_client_connections verstößt, wird die Verbindung abgebrochen.

Basierend auf dem Pooling Modus wartet PgBouncer auf eine Gelegenheit, die Verbindung zurück zur Datenbank zu bringen:

  • Im Sitzungs-Pooling-Modus wird eine Verbindung nur dann an den Pool zurückgegeben, wenn ein Client die Sitzung schließt.
  • Im Transaktions-Pooling-Modus wird eine Verbindung nur dann an den Pool zurückgegeben, wenn ein Client eine Transaktion abschließt (normalerweise wird entweder ein Rollback oder ein Commit ausgeführt). Daher werden sitzungsbasierte Funktionen in diesem Modus nicht unterstützt. Es gibt keine Garantie, dass zwei Transaktionen, die auf derselben Client-PgBouncer-Verbindung ausgeführt werden, auf derselben PgBouncer-Serververbindung ausgeführt werden.
  • Im Anweisungs-Pooling-Modus wird eine Verbindung an den Pool zurückgegeben, sobald eine Anweisung ausgeführt wird. Hier ist Autocommit immer eingeschaltet.

Bevor die Verbindung wieder an die Datenbank zurückgegeben wird, führt PgBouncer eine Reset-Abfrage aus, um alle Sitzungsinformationen zu entfernen – dies macht es sicher, Verbindungen zwischen Clients zu teilen. Es ist möglich, diese Abfrage basierend auf den Anforderungen der Anwendung zu konfigurieren.

Der Transaktions-Pooling-Modus wird am häufigsten verwendet, obwohl der Sitzungs-Pooling-Modus für bestimmte Workloads nützlich sein kann. Sie können mehr über PgBouncer auf ihrer Wiki-Seite lesen.

PostgreSQL Connection Pooling:Teil 2 – PgBouncerClick To Tweet

Warum PgBouncer wählen?

Es gibt viele Gründe, warum PgBouncer die beliebteste Wahl ist, wenn es um das Verbindungspooling in PostgreSQL geht. Hier sind einige der besten Funktionen und Vorteile, die PgBouncer bietet:

  • Pooling-Modi – Indem Benutzern die Möglichkeit gegeben wird, zu entscheiden, wann eine Verbindung zum Pool zurückgegeben wird, kann PgBouncer eine Vielzahl von Anwendungsfällen unterstützen. Und da sich diese Einrichtung auf Poolebene befindet, könnten Sie den Transaktionsmodus (bessere Leistung) für Ihre üblichen Datenbankverbindungen und den Sitzungsmodus nur dann verwenden, wenn Sie Funktionen wie vorbereitete Anweisungen benötigen!
  • Einfache Einrichtung und Verwendung – PgBouncer ist einer der am einfachsten einzurichtenden PostgreSQL-Verbindungspooler und erfordert auch keine clientseitigen Codeänderungen.
  • Passthrough-Authentifizierung – PgBouncer ist einer der wenigen „Middleware“-Verbindungspooler, die einen Benutzer sicher authentifizieren können, ohne Zugriff auf seine Passwörter (in Klartext oder verschlüsselter Form) zu haben. Dadurch wird PgBouncer sicherer und viel einfacher zu warten – Sie müssen PgBouncer nicht jedes Mal aktualisieren, wenn ein Benutzer sein Passwort aktualisiert.
  • Leicht – Es ist ein einzelner Prozess, und alle Befehle vom Client und Antworten vom Server passieren PgBouncer ohne Verarbeitung. Es muss also nicht den gesamten Inhalt auf einmal „sehen“ und behält daher einen sehr geringen Speicherbedarf bei.
  • Skalierbarkeit und Leistung – Wie wir im letzten Teil unserer Serie ausführlicher besprechen werden, kann PgBouncer die Transaktionen pro Sekunde, die Ihr PostgreSQL-Server unterstützen kann, erheblich verbessern, und es lässt sich sehr gut auf eine sehr große Anzahl von Clients skalieren.

Was macht PgBouncer nicht?

PgBouncer ist zwar ein großartiger Verbindungspooler, unterstützt jedoch keinen automatischen Lastenausgleich oder Hochverfügbarkeit. Es wird empfohlen, andere gängige Linux-Tools wie HAProxy zu verwenden, um eine Architektur zu erstellen, die diese Funktionen unterstützt.

Schauen Sie sich unten die beispielhafte PostgreSQL-Architektur für Lesevorgänge mit Lastenausgleich an:

Hinweis – Der Master-Knoten (dass all diese Slaves würde replizieren von) wird im Diagramm nicht angezeigt.

Wie man PgBouncer einrichtet

Wenn Sie eine ScaleGrid-PostgreSQL-Bereitstellung haben, können Sie PgBouncer mit wenigen Klicks einrichten. Gehen Sie zur Detailansicht Ihres PostgreSQL-Clusters und klicken Sie auf das PgBouncer-Symbol. Sobald Sie „PgBouncer aktivieren“ auswählen, werden Ihnen Konfigurationsoptionen zum Anpassen Ihres Pooling-Modus und Ihrer Poolgröße angezeigt – Sie können die Standardeinstellungen akzeptieren (keine Sorge, Sie können sie jederzeit ohne Ausfallzeit ändern) und auf „Aktivieren“ klicken! P>

Und das war's! Sie können loslegen.

Wenn Sie eine Nicht-ScaleGrid-Bereitstellung haben, wird PgBouncer als Teil des PostgreSQL-Repository verteilt und kann mit den entsprechenden Paketmanagern installiert werden. Für detailliertere Anweisungen oder zum Erstellen aus dem Quellcode können Sie den Anweisungen in ihrem Blog folgen.

Nach der Installation müssen Sie für PgBouncer nur einige wenige Konfigurationsparameter einrichten, um loszulegen:

  1. Eine Liste mit (Benutzername, md5-verschlüsseltem Passwort) zur Authentifizierung von Clients oder eine Passthrough-Authentifizierungseinrichtung für eine sicherere Bereitstellung.
  2. Schnittstellen/IP:Ports zum Abhören eingehender Verbindungen.
  3. Pool-Definitionen. Ein „Pool“ ist ein Name, den Clients als Datenbanknamen verwenden, wenn sie sich mit PgBouncer verbinden – er kann einer vollständigen Verbindungszeichenfolge (Host, Port, Datenbankname und Benutzer) zugeordnet werden. Die einfachste Definition hat die Form:
    * = host=
    Dies erstellt dynamische Pools für jede Kombination aus DB-Name und Benutzer und verbindet sich mit dem definierten Host unter Verwendung des vom Benutzer bereitgestellten Ports, DB-Namens und Benutzernamens.

Und das war's! Mit PgBouncer können Sie sehr schnell einsatzbereit sein. Es gibt jedoch noch viele weitere Einstellungen, die für jede Produktionsdistribution angepasst werden müssen – diese würden den Rahmen dieses Blogposts sprengen, aber Sie können mehr darüber in dieser PgBouncer-Konfigurationsübersicht lesen.

PgBouncer ist jedoch nicht die einzige Option für das PostgreSQL-Verbindungspooling – in unserem nächsten Beitrag werden wir Pgpool-II besprechen, das wahrscheinlich die wichtigste ist Konkurrent von PgBouncer. Bleiben Sie dran für unseren vierten Beitrag in dieser vierteiligen Serie, in dem wir PgBouncer vs. Pgpool-II vergleichen.