In unseren vorherigen Beiträgen in dieser Serie haben wir den Fall des Verbindungspoolings diskutiert und PgBouncer vorgestellt. In diesem Beitrag werden wir die beliebteste Alternative diskutieren – Pgpool-II.
Pgpool-II ist das Schweizer Taschenmesser der PostgreSQL-Middleware. Es unterstützt Hochverfügbarkeit, bietet automatisierten Lastausgleich und verfügt über die Intelligenz, die Last zwischen Mastern und Slaves auszugleichen, sodass Schreiblasten immer an Master gerichtet sind, während Leselasten an Slaves gerichtet sind. Pgpool-II bietet auch eine logische Replikation. Obwohl seine Verwendung und Bedeutung mit der Verbesserung der integrierten Replikationsoptionen auf der PostgreSQL-Serverseite abgenommen hat, bleibt dies immer noch eine wertvolle Option für ältere Versionen von PostgreSQL. Darüber hinaus bietet es auch Connection Pooling!
Auf einen Blick | ||||||
|---|---|---|---|---|---|---|
|
Pgpool-II einrichten
Pgpool-II-Binärdateien werden über die Repositories von Pgpool-II verteilt – Sie können mehr über die Installation in diesem Hilfedokument lesen. Nach der Installation müssen wir Pgpool-II konfigurieren, um die gewünschten Dienste zu aktivieren, und eine Verbindung zum PostgreSQL-Server herstellen. Hier können Sie mehr darüber lesen.
Um eine minimale Pooling-Einrichtung zu erhalten, müssen Sie Folgendes bereitstellen:
- Der Benutzername und das md5-verschlüsselte Passwort des/der Benutzer(s), die sich mit Pgpool-II verbinden – dies muss in einer separaten Datei definiert werden, die einfach mit dem pg_md5-Dienstprogramm generiert werden kann.
- Schnittstellen/IP-Adressen und Portnummer zum Abhören eingehender Verbindungen – dies muss in der Konfigurationsdatei definiert werden.
- Der Hostname des/der Backend-Server [mehr als ein Server wird nur angegeben, wenn wir Replikation und/oder Lastenausgleich verwenden möchten].
- Die Dienste, die Sie aktivieren möchten. In der Konfigurationsdatei, die mit den Binärdateien installiert wird, ist das Verbindungspooling standardmäßig aktiviert und andere Dienste sind deaktiviert.
Und fertig – wir sind startklar! Während die mit Pgpool-II verfügbaren Konfigurationen auf den ersten Blick einschüchternder sein mögen, haben es uns die Leute hinter Pgpool-II wirklich leicht gemacht!
Wie es funktioniert
Pgpool-II hat eine kompliziertere Architektur als PgBouncer, um alle seine Funktionen zu unterstützen. In diesem Abschnitt beschränken wir uns jedoch darauf, zu beschreiben, wie Connection Pooling funktioniert.
Der übergeordnete Prozess von Pgpool-II verzweigt standardmäßig 32 untergeordnete Prozesse – diese sind für die Verbindung verfügbar. Die Architektur ähnelt dem PostgreSQL-Server:ein Prozess =eine Verbindung. Es gibt auch den „PCP-Prozess“ ab, der für administrative Aufgaben verwendet wird und über den Rahmen dieses Beitrags hinausgeht. Die 32 Kinder sind nun bereit, Verbindungen anzunehmen. Wie PgBouncer emulieren auch diese einen PostgreSQL-Server – Clients können sich mit genau derselben Verbindungszeichenfolge wie mit einem normalen PostgreSQL-Server verbinden.
Der Kernel leitet eingehende Verbindungen zu einem der untergeordneten Prozesse, die sich als Listener registriert haben. Weder der Hauptprozess von Pgpool-II noch die Endbenutzer haben Einfluss darauf, welcher untergeordnete Prozess auf eine eingehende Anfrage antwortet. Jedes untätige Kind kann die Anfrage aufnehmen. Wenn keine untätigen untergeordneten Elemente gefunden werden, wird die Verbindungsanforderung auf der Kernelseite in eine Warteschlange gestellt – dies kann dazu führen, dass Anwendungen wie pgbench hängen bleiben und auf Clientverbindungen warten.
Sobald ein inaktives Pgpool-II-Kind eine Verbindungsanfrage erhält, wird es:
- Überprüft den Benutzernamen in seiner Passwortdatei. Wenn es nicht gefunden wird, lehnt es die Verbindung ab.
- Wenn der Benutzername gefunden wird, wird das angegebene Passwort mit dem in dieser Datei gespeicherten md5-Hash verglichen.
- Sobald die Authentifizierung erfolgreich war, prüft es, ob es bereits eine zwischengespeicherte Verbindung für diese Kombination aus Datenbank und Benutzer gibt.
- Wenn dies der Fall ist, wird die Verbindung zum Client zurückgegeben. Wenn dies nicht der Fall ist, wird eine neue Verbindung geöffnet.
- Alle Anfragen und Antworten passieren Pgpool-II, während es darauf wartet, dass der Client die Verbindung trennt.
- Sobald der Client die Verbindung trennt, muss Pgpool-II entscheiden, ob die Verbindung zwischengespeichert werden soll:
- Wenn es einen leeren Steckplatz hat, wird es zwischengespeichert.
- Wenn es keinen leeren Slot hat (d. h. das Zwischenspeichern dieser Verbindung würde die zulässige max_pool_size überschreiten), entscheidet es basierend auf einem internen Algorithmus.
- Wenn es sich entscheidet, die Verbindung zwischenzuspeichern, führt es die vorkonfigurierte Reset-Abfrage aus, um alle Sitzungsdetails zu bereinigen und sie für die Wiederverwendung durch einen anderen Client sicher zu machen.
- Jetzt kann der untergeordnete Prozess mehr Verbindungen aufnehmen.
|
Was macht Pgpool-II nicht?
Leider ist für diejenigen, die sich nur auf das Verbindungspooling konzentrieren, Pgpool-II nicht sehr gut im Verbindungspooling, insbesondere für eine kleine Anzahl von Clients. Da jeder untergeordnete Prozess seinen eigenen Pool hat und es keine Möglichkeit gibt, zu steuern, welcher Client sich mit welchem untergeordneten Prozess verbindet, bleibt zu viel dem Glück überlassen, wenn es um die Wiederverwendung von Verbindungen geht.
Wie Sie sehen können, haben Pgpool und PgBouncer ziemlich unterschiedliche Stärken – in unserem letzten Beitrag der Serie werden wir einen Kopf-an-Kopf-Test durchführen , und Funktionsvergleich! Bleiben Sie dran!
PostgreSQL Connection Pooling-Reihe
|
|---|
