Dokumentation zu PgBouncer 1.25.2

• 1: Funktionen
• 2: Verwendung: pgbouncer-Befehl
• 3: PgBouncer kompilieren und installieren
• 4: Quellcode-Releases zum Download
• 5: Community
• 6: Häufig gestellte Fragen

1 - Funktionen

• Mehrere Pooling-Modi mit unterschiedlich restriktiver Verbindungszuweisung:

  Sitzungs-Pooling

  Die am wenigsten restriktive Methode. Wenn ein Client eine Verbindung herstellt, wird ihm für die gesamte Dauer der Clientverbindung eine Serververbindung zugewiesen. Trennt der Client die Verbindung, wird die Serververbindung wieder in den Pool zurückgegeben. Dieser Modus unterstützt sämtliche PostgreSQL-Funktionen.

  Transaktions-Pooling

  Eine Serververbindung wird einem Client nur für die Dauer einer Transaktion zugewiesen. Sobald PgBouncer erkennt, dass die Transaktion beendet ist, wird die Serververbindung wieder in den Pool zurückgegeben. Dieser Modus ist mit einigen sitzungsbezogenen Funktionen von PostgreSQL nicht kompatibel. Er kann nur eingesetzt werden, wenn die Anwendung darauf abgestimmt ist und keine inkompatiblen Funktionen verwendet. Die folgende Tabelle führt diese Funktionen auf.

  Statement-Pooling

  Die restriktivste Methode. Sie entspricht dem Transaktions-Pooling, lässt jedoch keine Transaktionen mit mehreren Anweisungen zu. Damit wird auf der Clientseite der „Autocommit“-Modus erzwungen; der Modus ist vor allem für PL/Proxy vorgesehen.

• Geringer Speicherbedarf (standardmäßig 2 kB pro Verbindung), da PgBouncer vollständige Pakete nicht auf einmal einlesen muss.

• PgBouncer ist nicht an einen einzelnen Backend-Server gebunden. Die Zieldatenbanken können sich auf unterschiedlichen Hosts befinden.

• Unterstützt für die meisten Einstellungen eine Neukonfiguration im laufenden Betrieb.

• Unterstützt Neustarts und Upgrades im laufenden Betrieb, ohne Clientverbindungen zu trennen.

SQL-Funktionsmatrix für Pooling-Modi

Die folgende Tabelle zeigt verschiedene PostgreSQL-Funktionen und ihre Kompatibilität mit den Pooling-Modi von PgBouncer. Beachten Sie, dass das Transaktions-Pooling das vom Client erwartete Serververhalten bewusst verändert. Es kann daher nur verwendet werden, wenn die Anwendung darauf abgestimmt ist und keine inkompatiblen Funktionen nutzt.

2 - Verwendung: pgbouncer-Befehl

Zusammenfassung

pgbouncer [-d][-R][-v][-u user] <pgbouncer.ini>
pgbouncer -V|-h

Unter Windows stehen folgende Optionen zur Verfügung:

pgbouncer.exe [-v][-u user] <pgbouncer.ini>
pgbouncer.exe -V|-h

Zusätzliche Optionen zur Einrichtung eines Windows-Dienstes:

pgbouncer.exe --regservice   <pgbouncer.ini>
pgbouncer.exe --unregservice <pgbouncer.ini>

Beschreibung

pgbouncer ist ein PostgreSQL-Verbindungspooler. Jede Zielanwendung kann sich mit pgbouncer verbinden, als wäre PgBouncer ein PostgreSQL-Server. pgbouncer stellt dann eine Verbindung zum tatsächlichen Server her oder verwendet eine bereits vorhandene Verbindung wieder.

Das Ziel von pgbouncer ist es, die Auswirkungen auf die Leistung beim Öffnen neuer Verbindungen zu PostgreSQL zu reduzieren.

Um die Transaktionssemantik beim Pooling von Verbindungen nicht zu beeinträchtigen, unterstützt pgbouncer beim Wechsel der Verbindungen mehrere Pooling-Varianten:

Sitzungs-Pooling

Die am wenigsten restriktive Methode. Sobald ein Client eine Verbindung herstellt, wird ihm für die gesamte Verbindungsdauer eine Serververbindung zugewiesen. Trennt der Client die Verbindung, wird die Serververbindung wieder in den Pool zurückgegeben. Dies ist die Standardmethode.

Transaktions-Pooling

Eine Serververbindung wird einem Client nur für die Dauer einer Transaktion zugewiesen. Sobald PgBouncer erkennt, dass die Transaktion beendet ist, wird die Serververbindung wieder in den Pool zurückgegeben.

Statement-Pooling

Die restriktivste Methode. Die Serververbindung wird unmittelbar nach Abschluss einer Abfrage in den Pool zurückgegeben. Transaktionen mit mehreren Anweisungen sind in diesem Modus nicht zulässig, da sie sonst nicht funktionieren würden.

Die Administrationsoberfläche von pgbouncer umfasst einige zusätzliche SHOW-Befehle. Sie stehen bei einer Verbindung mit der speziellen „virtuellen“ Datenbank pgbouncer zur Verfügung.

Schnellstart

Die grundlegende Einrichtung und Verwendung erfolgen wie folgt:

1. Erstellen Sie eine Datei namens pgbouncer.ini. Weitere Informationen finden Sie in pgbouncer(5). Ein einfaches Beispiel:

    [databases]
    template1 = host=localhost port=5432 dbname=template1
   
    [pgbouncer]
    listen_port = 6432
    listen_addr = localhost
    auth_type = md5
    auth_file = userlist.txt
    logfile = pgbouncer.log
    pidfile = pgbouncer.pid
    admin_users = someuser
   

2. Erstellen Sie eine Datei mit dem Namen userlist.txt, die die Benutzer enthält, die sich anmelden dürfen:

    "someuser" "same_password_as_in_server"
   

3. Starten Sie pgbouncer:

    $ pgbouncer -d pgbouncer.ini
   

4. Lassen Sie Ihre Anwendung (oder den psql-Client) eine Verbindung mit pgbouncer statt direkt mit dem PostgreSQL-Server herstellen:

    $ psql -p 6432 -U someuser template1
   

5. Verwalten Sie pgbouncer, indem Sie sich mit der speziellen Administrationsdatenbank pgbouncer verbinden und zunächst den Befehl SHOW HELP; ausführen:

    $ psql -p 6432 -U someuser pgbouncer
    pgbouncer=# SHOW HELP;
    NOTICE:  Console usage
    DETAIL:
      SHOW [HELP|CONFIG|DATABASES|FDS|POOLS|CLIENTS|SERVERS|SOCKETS|LISTS|VERSION|...]
      SET key = arg
      RELOAD
      PAUSE
      SUSPEND
      RESUME
      SHUTDOWN
      [...]
   

6. Wenn Sie pgbouncer.ini geändert haben, können Sie die Datei mit folgendem Befehl neu laden:

    pgbouncer=# RELOAD;
   

Befehlszeilenoptionen

-d, --daemon

Im Hintergrund ausführen. Ohne diese Option wird der Prozess im Vordergrund ausgeführt.

Im Daemon-Modus müssen sowohl pidfile als auch logfile oder syslog festgelegt sein. Nach dem Wechsel in den Hintergrund werden keine Protokollmeldungen mehr auf stderr ausgegeben.

Hinweis: Funktioniert nicht unter Windows; dort muss pgbouncer als Dienst ausgeführt werden.

-R, --reboot

VERALTET (DEPRECATED): Verwenden Sie statt dieser Option einen rollierenden Neustart mit mehreren pgbouncer-Prozessen, die mithilfe von so_reuseport am selben Port lauschen. Führt einen Online-Neustart durch. Dazu verbindet sich der neue Prozess mit dem laufenden Prozess, übernimmt dessen offene Sockets und verwendet sie anschließend. Ist kein Prozess aktiv, startet er normal. Hinweis: Funktioniert nur, wenn das Betriebssystem Unix-Sockets unterstützt und unix_socket_dir in der Konfiguration nicht deaktiviert ist. Funktioniert nicht unter Windows. Funktioniert nicht mit TLS-Verbindungen; diese werden getrennt.

-u USERNAME, --user= USERNAME

Beim Start zum angegebenen Benutzer wechseln.

-v, --verbose

Ausführlichkeit erhöhen. Kann mehrfach angegeben werden.

-q, --quiet

Keine Protokollausgabe auf stderr. Dies beeinflusst nicht die Ausführlichkeit der Protokollierung, sondern nur die Verwendung von stderr. Für den Einsatz in init.d-Skripten vorgesehen.

-V, --version

Version anzeigen.

-h, --help

Kurzhilfe anzeigen.

--regservice

Win32: PgBouncer als Windows-Dienst registrieren. Der Wert des Konfigurationsparameters service_name wird als Registrierungsname verwendet.

--unregservice

Win32: Registrierung des Windows-Dienstes aufheben.

Admin-Konsole

Die Konsole ist über eine normale Verbindung zur Datenbank pgbouncer erreichbar:

$ psql -p 6432 pgbouncer

Nur Benutzer, die in den Konfigurationsparametern admin_users oder stats_users aufgeführt sind, dürfen sich an der Konsole anmelden. (Bei auth_type=any ist dagegen jeder Benutzer als stats_user zugelassen.)

Zusätzlich darf sich der Benutzer pgbouncer ohne Passwort anmelden, sofern die Anmeldung über einen Unix-Socket erfolgt und der Client dieselbe Unix-Benutzer-ID (UID) wie der laufende Prozess besitzt.

Die Admin-Konsole unterstützt derzeit nur das einfache Abfrageprotokoll. Einige Treiber verwenden für alle Befehle das erweiterte Abfrageprotokoll und können daher nicht mit der Admin-Konsole verwendet werden.

Anzeigebefehle

Die SHOW-Befehle geben Informationen aus. Jeder Befehl wird nachfolgend beschrieben.

SHOW STATS

Zeigt Statistiken an. Die Gesamtwerte in diesem und verwandten Befehlen beziehen sich auf den Zeitraum seit dem Prozessstart; die Durchschnittswerte werden nach jedem stats_period-Intervall aktualisiert.

database

Statistiken werden pro Datenbank angezeigt.

total_xact_count

Gesamtanzahl der von pgbouncer gepoolten SQL-Transaktionen.

total_query_count

Gesamtanzahl der von pgbouncer gepoolten SQL-Befehle.

total_server_assignment_count

Gesamtzahl der Zuweisungen eines Servers an einen Client.

total_received

Gesamtvolumen des von pgbouncer empfangenen Netzwerkverkehrs in Byte.

total_sent

Gesamtvolumen des von pgbouncer gesendeten Netzwerkverkehrs in Byte.

total_xact_time

Gesamtzahl der Mikrosekunden, die pgbouncer während einer Transaktion mit PostgreSQL verbunden war – entweder im Leerlauf innerhalb der Transaktion oder bei der Ausführung von Abfragen.

total_query_time

Gesamtzahl der Mikrosekunden, die pgbouncer aktiv mit PostgreSQL verbunden war und Abfragen ausführte.

total_wait_time

Gesamte Wartezeit der Clients auf einen Server in Mikrosekunden. Sie wird aktualisiert, wenn einer Clientverbindung eine Backendverbindung zugewiesen wird.

total_client_parse_count

Gesamtzahl der von Clients erstellten vorbereiteten Anweisungen. Nur bei der Nachverfolgung benannter vorbereiteter Anweisungen relevant, siehe max_prepared_statements.

total_server_parse_count

Gesamtzahl der von pgbouncer auf einem Server erstellten vorbereiteten Anweisungen. Nur bei der Nachverfolgung benannter vorbereiteter Anweisungen relevant, siehe max_prepared_statements.

total_bind_count

Gesamtzahl der vorbereiteten Anweisungen, die von Clients zur Ausführung bereitgestellt und von pgbouncer an PostgreSQL weitergeleitet wurden. Nur bei der Nachverfolgung benannter vorbereiteter Anweisungen relevant, siehe max_prepared_statements.

avg_xact_count

Durchschnittliche Anzahl von Transaktionen pro Sekunde im letzten Statistikzeitraum.

avg_query_count

Durchschnittliche Anzahl von Abfragen pro Sekunde im letzten Statistikzeitraum.

avg_server_assignment_count

Durchschnittliche Anzahl der Zuweisungen eines Servers an einen Client pro Sekunde im letzten Statistikzeitraum.

avg_recv

Durchschnittlich pro Sekunde empfangene Byte (von Clients).

avg_sent

Durchschnittlich pro Sekunde gesendete Byte (an Clients).

avg_xact_time

Durchschnittliche Transaktionsdauer in Mikrosekunden.

avg_query_time

Durchschnittliche Abfragezeit in Mikrosekunden.

avg_wait_time

Wartezeit der Clients auf einen Server in Mikrosekunden (Durchschnitt der Wartezeiten für Clients, die während des aktuellen stats_period einem Backend zugewiesen wurden).

avg_client_parse_count

Durchschnittliche Zahl der von Clients erstellten vorbereiteten Anweisungen. Nur bei der Nachverfolgung benannter vorbereiteter Anweisungen relevant, siehe max_prepared_statements.

avg_server_parse_count

Durchschnittliche Zahl der von pgbouncer auf einem Server erstellten vorbereiteten Anweisungen. Nur bei der Nachverfolgung benannter vorbereiteter Anweisungen relevant, siehe max_prepared_statements.

avg_bind_count

Durchschnittliche Zahl der vorbereiteten Anweisungen, die von Clients zur Ausführung bereitgestellt und von pgbouncer an PostgreSQL weitergeleitet wurden. Nur bei der Nachverfolgung benannter vorbereiteter Anweisungen relevant, siehe max_prepared_statements.

SHOW STATS_TOTALS

Teilmenge von SHOW STATS mit den Gesamtwerten (total_).

SHOW STATS_AVERAGES

Teilmenge von SHOW STATS mit den Durchschnittswerten (avg_).

SHOW TOTALS

Wie SHOW STATS, jedoch über alle Datenbanken aggregiert.

SHOW SERVERS

type

S für Server.

user

Benutzername, mit dem pgbouncer die Verbindung zum Server herstellt.

database

Datenbankname.

replication

Gibt an, ob die Serververbindung Replikation nutzt. Kann none, logical oder physical sein.

state

Zustand der PgBouncer-Serververbindung, einer der folgenden: active, idle, used, tested, new, active_cancel, being_canceled.

addr

IP-Adresse des PostgreSQL-Servers.

port

Port des PostgreSQL-Servers.

local_addr

Verbindungsstartadresse auf dem lokalen Computer.

local_port

Verbindungsstartport auf dem lokalen Computer.

connect_time

Zeitpunkt des Verbindungsaufbaus.

request_time

Zeitpunkt der letzten Anfrage.

wait

Nicht für Serververbindungen verwendet.

wait_us

Nicht für Serververbindungen verwendet.

close_needed

1, wenn die Verbindung so schnell wie möglich geschlossen werden soll, weil das Neuladen einer Konfigurationsdatei oder eine DNS-Aktualisierung die Verbindungsinformationen geändert hat oder RECONNECT ausgeführt wurde.

ptr

Adresse des internen Objekts für diese Verbindung.

link

Adresse der Clientverbindung, mit der der Server verknüpft ist.

remote_pid

PID des Backend-Serverprozesses. Wurde die Verbindung über einen Unix-Socket hergestellt und unterstützt das Betriebssystem das Abrufen von Prozess-ID-Informationen, ist dies die Betriebssystem-PID. Andernfalls wird der Wert aus dem vom Server gesendeten Abbruchpaket entnommen; bei einem PostgreSQL-Server sollte dies die PID sein, bei einer anderen PgBouncer-Instanz kann es eine Zufallszahl sein.

tls

Eine Zeichenkette mit TLS-Verbindungsinformationen oder leer, wenn TLS nicht verwendet wird.

application_name

Ein String, der den application_name auf der verknüpften Clientverbindung enthält, oder leer, wenn dieser nicht gesetzt ist oder keine verknüpfte Verbindung besteht.

prepared_statements

Die Anzahl der auf dem Server vorbereiteten Anweisungen. Diese Zahl ist durch die Einstellung max_prepared_statements begrenzt.

id

Eindeutige ID für den Server.

SHOW CLIENTS

type

C für Client.

user

Benutzername der Clientverbindung.

database

Datenbankname.

replication

Gibt an, ob die Clientverbindung Replikation nutzt. Kann none, logical oder physical sein.

state

Zustand der Clientverbindung, einer der Werte active (Clientverbindungen, die mit Serververbindungen verknüpft sind), idle (Clientverbindungen ohne ausstehende Abfragen), waiting, active_cancel_req oder waiting_cancel_req.

addr

IP-Adresse des Clients.

port

Quellport des Clients.

local_addr

Lokale Endadresse der Verbindung.

local_port

Lokaler Endport der Verbindung.

connect_time

Zeitstempel des Verbindungsaufbaus.

request_time

Zeitstempel der letzten Clientanfrage.

wait

Aktuelle Wartezeit in Sekunden.

wait_us

Mikrosekundenanteil der aktuellen Wartezeit.

close_needed

Nicht für Clients verwendet.

ptr

Adresse des internen Objekts für diese Verbindung.

link

Adresse der Serververbindung, der der Client zugeordnet ist.

remote_pid

Prozess-ID, falls der Client über einen Unix-Socket verbunden ist und das Betriebssystem die ID abrufen kann.

tls

Ein String mit TLS-Verbindungsinformationen oder leer, falls TLS nicht verwendet wird.

application_name

Ein String, der den application_name enthält, der vom Client für diese Verbindung festgelegt wurde, oder leer, falls kein solcher Wert gesetzt wurde.

prepared_statements

Anzahl der vom Client vorbereiteten Anweisungen.

id

Eindeutige ID für den Client.

SHOW POOLS

Für jede Kombination aus Datenbank und Benutzer wird ein neuer Pool-Eintrag erstellt.

database

Datenbankname.

user

Benutzername.

cl_active

Clientverbindungen, die entweder Serververbindungen zugeordnet sind oder sich im Leerlauf befinden, ohne dass Abfragen zur Verarbeitung anstehen.

cl_waiting

Clientverbindungen, die Abfragen gesendet, aber noch keine Serververbindung erhalten haben.

cl_active_cancel_req

Clientverbindungen, die Abfrageabbrüche an den Server weitergeleitet haben und auf dessen Antwort warten.

cl_waiting_cancel_req

Clientverbindungen, die noch keine Abbruchanfragen an den Server weitergeleitet haben.

sv_active

Serververbindungen, die mit einem Client verbunden sind.

sv_active_cancel

Serververbindungen, die derzeit eine Abbruchanforderung weiterleiten.

sv_being_canceled

Serververbindungen, die normalerweise in den Leerlauf wechseln könnten, damit jedoch warten, bis alle noch laufenden Anforderungen zum Abbruch einer Abfrage auf diesem Server abgeschlossen sind.

sv_idle

Serververbindungen, die ungenutzt sind und sofort für Clientanfragen verwendet werden können.

sv_used

Serververbindungen, die länger als server_check_delay inaktiv waren, sodass server_check_query ausgeführt werden muss, bevor sie erneut verwendet werden können.

sv_tested

Serververbindungen, die derzeit entweder server_reset_query oder server_check_query ausführen.

sv_login

Serververbindungen, die gerade angemeldet werden.

maxwait

Bisherige Wartezeit des ersten (ältesten) Clients in der Warteschlange in Sekunden. Steigt dieser Wert, verarbeitet der aktuelle Serverpool die Anfragen nicht schnell genug. Ursache kann ein überlasteter Server oder eine zu kleine pool_size-Einstellung sein.

maxwait_us

Mikrosekundenanteil der maximalen Wartezeit.

pool_mode

Der verwendete Pool-Modus.

load_balance_hosts

Die verwendete load_balance_hosts-Einstellung, wenn der Host des Pools eine kommagetrennte Liste enthält.

SHOW PEER_POOLS

Für jeden konfigurierten Peer wird ein neuer peer_pool-Eintrag erstellt.

database

ID des konfigurierten Peer-Eintrags.

cl_active_cancel_req

Clientverbindungen, die Abfrageabbrüche an den Server weitergeleitet haben und auf dessen Antwort warten.

cl_waiting_cancel_req

Clientverbindungen, die Abbruchanfragen noch nicht an den Server weitergeleitet haben.

sv_active_cancel

Serververbindungen, die derzeit eine Abbruchanforderung weiterleiten.

sv_login

Serververbindungen, deren Anmeldung gerade läuft.

SHOW LISTS

Zeigt die folgenden internen Informationen in Spalten (nicht Zeilen) an:

databases

Anzahl der Datenbanken.

users

Anzahl der Benutzer.

pools

Anzahl der Pools.

free_clients

Anzahl freier Clients. Diese Clients sind getrennt, PgBouncer behält jedoch den für sie reservierten Speicher bei, um ihn für künftige Clients wiederzuverwenden und neue Speicherzuweisungen zu vermeiden.

used_clients

Anzahl genutzter Clients.

login_clients

Anzahl der Clients im login-Zustand.

free_servers

Anzahl freier Server. Diese Server sind getrennt, PgBouncer behält jedoch den für sie reservierten Speicher bei, um ihn für künftige Server wiederzuverwenden und neue Speicherzuweisungen zu vermeiden.

used_servers

Anzahl genutzter Server.

dns_names

Anzahl der DNS-Namen im Cache.

dns_zones

Anzahl der DNS-Zonen im Cache.

dns_queries

Anzahl der laufenden DNS-Abfragen.

dns_pending

Nicht verwendet.

SHOW USERS

name

Der Benutzername.

pool_size

Benutzerspezifische Überschreibung von pool_size oder NULL, falls nicht gesetzt.

reserve_pool_size

Benutzerspezifische Überschreibung von reserve_pool_size oder NULL, falls nicht gesetzt.

pool_mode

Benutzerspezifische Überschreibung von pool_mode oder NULL, falls nicht gesetzt.

max_user_connections

Benutzerspezifische Einstellung max_user_connections. Ist sie für diesen Benutzer nicht gesetzt, wird der Standardwert angezeigt.

current_connections

Aktuelle Anzahl der Serververbindungen, die dieser Benutzer zu allen Servern geöffnet hat.

max_user_client_connections

Benutzerspezifische Einstellung max_user_client_connections. Ist sie für diesen Benutzer nicht gesetzt, wird der Standardwert angezeigt.

current_client_connections

Aktuelle Anzahl der Clientverbindungen, die dieser Benutzer zu PgBouncer geöffnet hat.

SHOW DATABASES

name

Name des konfigurierten Datenbankeintrags.

host

Host, zu dem PgBouncer eine Verbindung herstellt.

port

Port, zu dem PgBouncer eine Verbindung herstellt.

database

Tatsächlicher Name der Datenbank, zu der PgBouncer eine Verbindung herstellt.

force_user

Ist ein Benutzer Teil der Verbindungszeichenfolge, wird für die Verbindung zwischen PgBouncer und PostgreSQL unabhängig vom Clientbenutzer dieser angegebene Benutzer erzwungen.

pool_size

Maximale Anzahl an Serververbindungen.

min_pool_size

Minimale Anzahl an Serververbindungen.

reserve_pool_size

Maximale Anzahl zusätzlicher Verbindungen für diese Datenbank.

server_lifetime

Maximale Lebensdauer einer Serververbindung für diese Datenbank.

pool_mode

Datenbankspezifische Überschreibung von pool_mode oder NULL, wenn stattdessen der Standardwert verwendet wird.

load_balance_hosts

Datenbankspezifische load_balance_hosts-Einstellung, falls der Host eine kommagetrennte Liste enthält.

max_connections

Maximale Anzahl zulässiger Serververbindungen für diese Datenbank, wie durch max_db_connections global oder pro Datenbank festgelegt.

current_connections

Aktuelle Anzahl der Serververbindungen für diese Datenbank.

max_client_connections

Maximale Anzahl zulässiger Clientverbindungen für diese PgBouncer-Instanz, wie durch max_db_client_connections pro Datenbank festgelegt.

current_client_connections

Aktuelle Anzahl der Clientverbindungen für diese Datenbank.

paused

1, wenn diese Datenbank derzeit pausiert ist, sonst 0.

disabled

1, wenn diese Datenbank derzeit deaktiviert ist, sonst 0.

SHOW PEERS

peer_id

ID des konfigurierten Peer-Eintrags.

host

Host, zu dem PgBouncer eine Verbindung herstellt.

port

Port, zu dem PgBouncer eine Verbindung herstellt.

pool_size

Maximale Anzahl der Serververbindungen, die zu diesem Peer hergestellt werden können.

SHOW FDS

Interner Befehl – zeigt die Liste der verwendeten Dateideskriptoren mit ihrem internen Zustand.

Wenn der verbundene Benutzer „pgbouncer“ heißt, sich über einen Unix-Socket verbindet und dieselbe UID wie der laufende Prozess besitzt, werden die tatsächlichen FDs über die Verbindung übertragen. Dieses Verfahren wird für einen Online-Neustart verwendet. Hinweis: Dies funktioniert nicht unter Windows.

Da dieser Befehl außerdem die interne Ereignisschleife blockiert, sollte er nicht verwendet werden, während PgBouncer in Betrieb ist.

fd

Numerischer Wert des Dateideskriptors.

task

Einer der Werte pooler, client oder server.

user

Benutzer der Verbindung, die diesen FD verwendet.

database

Datenbank der Verbindung, die diesen FD verwendet.

addr

IP-Adresse der Verbindung, die den FD verwendet; unix, falls ein Unix-Socket verwendet wird.

port

Port der Verbindung, die den FD verwendet.

cancel

Abbruchschlüssel für diese Verbindung.

link

FD des zugehörigen Servers/Clients. NULL im Leerlauf.

SHOW SOCKETS, SHOW ACTIVE_SOCKETS

Zeigt systemnahe Informationen über alle oder nur die aktiven Sockets an. Dazu gehören die unter SHOW CLIENTS und SHOW SERVERS angezeigten Informationen sowie weitere systemnahe Angaben.

SHOW CONFIG

Zeigt die aktuellen Konfigurationseinstellungen mit einer Einstellung pro Zeile und den folgenden Spalten:

key

Name der Konfigurationsvariable.

value

Konfigurationswert.

default

Standardwert der Konfiguration.

changeable

Gibt mit yes oder no an, ob die Variable zur Laufzeit geändert werden kann. Wenn no, kann die Variable nur beim Start geändert werden. Verwenden Sie SET, um eine Variable zur Laufzeit zu ändern.

SHOW MEM

Zeigt systemnahe Informationen über die aktuellen Größen verschiedener interner Speicherreservierungen an. Diese Angaben können sich ändern.

SHOW DNS_HOSTS

Zeigt Hostnamen im DNS-Cache an.

hostname

Hostname.

ttl

Sekunden bis zur nächsten Abfrage.

addrs

Kommagetrennte Liste von Adressen.

SHOW DNS_ZONES

Zeigt DNS-Zonen im Cache an.

zonename

Zonenname.

serial

Aktuelle Seriennummer.

count

Anzahl von Hostnamen, die dieser Zone zugeordnet sind.

SHOW VERSION

Zeigt die PgBouncer-Version als Zeichenkette an.

SHOW STATE

Zeigt die Zustandseinstellungen von PgBouncer an. Mögliche Zustände sind active, paused und suspended.

Befehle zur Prozesskontrolle

PAUSE [db]

PgBouncer versucht, alle Serververbindungen zu trennen. Jede Verbindung wird erst getrennt, nachdem sie entsprechend dem Pooling-Modus des Serverpools freigegeben wurde (beim Transaktions-Pooling muss die Transaktion abgeschlossen sein, beim Statement-Pooling die Anweisung und beim Sitzungs-Pooling muss der Client die Verbindung trennen). Der Befehl kehrt erst zurück, nachdem alle Serververbindungen getrennt wurden. Für Datenbankneustarts vorgesehen.

Wird ein Datenbankname angegeben, wird nur diese Datenbank pausiert.

Neue Clientverbindungen zu einer pausierten Datenbank warten, bis RESUME aufgerufen wird.

DISABLE db

Weist alle neuen Clientverbindungen zur angegebenen Datenbank ab.

ENABLE db

Ermöglicht nach einem vorherigen DISABLE-Befehl wieder neue Clientverbindungen.

RECONNECT [db]

Schließt jede offene Serververbindung für die angegebene Datenbank oder für alle Datenbanken, sobald sie entsprechend dem Pooling-Modus freigegeben wird, selbst wenn ihre Lebensdauer noch nicht abgelaufen ist. Neue Serververbindungen können sofort hergestellt werden und verbinden sich bei Bedarf gemäß den Einstellungen der Poolgröße.

Dieser Befehl ist nützlich, wenn sich die Einrichtung der Serververbindung geändert hat, etwa für einen schrittweisen Wechsel zu einem neuen Server. Er muss nicht ausgeführt werden, wenn die Verbindungszeichenfolge in pgbouncer.ini geändert und neu geladen wurde (siehe RELOAD) oder wenn sich die DNS-Auflösung geändert hat; in diesen Fällen wird ein gleichwertiger Befehl automatisch ausgeführt. Er ist nur erforderlich, wenn eine dem PgBouncer nachgelagerte Komponente die Verbindungen weiterleitet.

Nach Ausführung dieses Befehls kann es längere Zeit dauern, bis alle Serververbindungen zum neuen Ziel führen; einige können noch das alte Ziel verwenden. Dies ist voraussichtlich nur beim Umschalten von schreibgeschütztem Datenverkehr zwischen schreibgeschützten Replikaten oder zwischen Knoten einer Multimaster-Replikation sinnvoll. Müssen alle Verbindungen gleichzeitig umgeschaltet werden, wird stattdessen PAUSE empfohlen. Sollen Serververbindungen ohne Wartezeit geschlossen werden, etwa bei einem Notfall-Failover statt eines schrittweisen Switchovers, kommt auch KILL infrage.

KILL [db]

Trennt sofort alle Client- und Serververbindungen für die angegebene Datenbank oder für alle Datenbanken mit Ausnahme der Administrationsdatenbank.

Neue Clientverbindungen zu einer Datenbank, für die KILL ausgeführt wurde, warten, bis RESUME aufgerufen wird.

KILL_CLIENT id

Trennt sofort die angegebene Clientverbindung sowie alle Serververbindungen des betreffenden Clients. Der Client, dessen Verbindung getrennt werden soll, wird durch den id-Wert identifiziert, der mit dem Befehl SHOW CLIENTS ermittelt werden kann.

Ein Beispielbefehl sieht etwa so aus: KILL_CLIENT 1234.

SUSPEND

Alle Socket-Puffer werden geleert, und PgBouncer nimmt auf diesen Sockets keine Daten mehr entgegen. Der Befehl kehrt erst zurück, wenn alle Puffer leer sind. Er ist für einen Online-Neustart von PgBouncer vorgesehen.

Neue Clientverbindungen zu einer suspendierten Datenbank warten, bis RESUME aufgerufen wird.

RESUME [db]

Nimmt den Betrieb nach einem vorherigen KILL-, PAUSE- oder SUSPEND-Befehl wieder auf.

SHUTDOWN

Der PgBouncer-Prozess wird beendet.

SHUTDOWN WAIT_FOR_SERVERS

Nimmt keine neuen Verbindungen mehr an und fährt herunter, nachdem alle Serververbindungen freigegeben wurden. Dies entspricht im Wesentlichen der Ausführung von PAUSE und SHUTDOWN. Zusätzlich werden bereits während des Wartens auf PAUSE keine neuen Verbindungen mehr angenommen und Clients, die auf eine Serververbindung warten, sofort getrennt. Beachten Sie, dass Unix-Sockets während des Herunterfahrens geöffnet bleiben, aber nur Verbindungen zur PgBouncer-Administrationskonsole annehmen.

SHUTDOWN WAIT_FOR_CLIENTS

Nimmt keine neuen Verbindungen mehr an und beendet den Prozess, sobald alle vorhandenen Clients ihre Verbindung getrennt haben. Beachten Sie, dass Unix-Sockets während des Herunterfahrens geöffnet bleiben, aber nur Verbindungen zur PgBouncer-Administrationskonsole annehmen. Mit diesem Befehl lässt sich nach dem folgenden Verfahren ein rollierender Neustart zweier PgBouncer-Prozesse ohne Ausfallzeit durchführen:

1. Lassen Sie zwei oder mehr PgBouncer-Prozesse mit so_reuseport auf demselben Port laufen (Peering konfigurieren wird empfohlen, ist aber nicht erforderlich). Für einen Neustart ohne Ausfallzeit werden diese Prozesse nacheinander neu gestartet. So können die übrigen weiterhin Verbindungen annehmen, während jeweils ein Prozess neu startet.
2. Wählen Sie den zuerst neu zu startenden Prozess; nennen wir ihn A.
3. Führen Sie für Prozess A SHUTDOWN WAIT_FOR_CLIENTS aus (oder senden Sie ihm SIGTERM).
4. Veranlassen Sie alle Clients, ihre Verbindung neu herzustellen. Warten Sie dazu etwa, bis der clientseitige Pooler aufgrund seines server_idle_timeout (oder einer ähnlichen Konfiguration) Neuverbindungen auslöst. Wird kein clientseitiger Pooler verwendet, können stattdessen die Clients neu gestartet werden. Sobald alle Clients wieder verbunden sind, beendet sich Prozess A automatisch, da keine Clients mehr mit ihm verbunden sind.
5. Starten Sie Prozess A erneut.
6. Wiederholen Sie die Schritte 3, 4 und 5 nacheinander für jeden verbleibenden Prozess, bis alle Prozesse neu gestartet wurden.

RELOAD

Der PgBouncer-Prozess lädt seine Konfigurationsdateien neu und aktualisiert änderbare Einstellungen. Dazu gehören die Hauptkonfigurationsdatei sowie die Dateien, die durch die Einstellungen auth_file und auth_hba_file angegeben sind.

PgBouncer erkennt, wenn das Neuladen einer Konfigurationsdatei die Verbindungsparameter einer Datenbankdefinition ändert. Eine vorhandene Serververbindung zum alten Ziel wird bei ihrer nächsten Freigabe entsprechend dem Pooling-Modus geschlossen; neue Serververbindungen verwenden sofort die aktualisierten Verbindungsparameter.

WAIT_CLOSE [db]

Wartet, bis alle Serververbindungen der angegebenen Datenbank oder aller Datenbanken den Zustand “close_needed” verlassen haben (siehe SHOW SERVERS). Der Befehl kann nach RECONNECT oder RELOAD aufgerufen werden, um zu warten, bis die jeweilige Konfigurationsänderung vollständig aktiviert ist, beispielsweise in Switchover-Skripten.

Weitere Befehle

SET key = arg

Ändert eine Konfigurationseinstellung (siehe auch SHOW CONFIG). Zum Beispiel:

SET log_connections = 1;
SET server_check_query = 'select 2';

(Beachten Sie, dass dieser Befehl in der PgBouncer-Administrationskonsole ausgeführt wird und PgBouncer-Einstellungen setzt. Ein in einer anderen Datenbank ausgeführter SET-Befehl wird wie jeder andere SQL-Befehl an das PostgreSQL-Backend weitergeleitet.)

Signale

SIGHUP

Konfiguration neu laden. Entspricht dem Befehl RELOAD an der Konsole.

SIGTERM

Besonders sicheres Herunterfahren. Wartet, bis alle vorhandenen Clients ihre Verbindung getrennt haben, nimmt jedoch keine neuen Verbindungen an. Dies entspricht SHUTDOWN WAIT_FOR_CLIENTS an der Konsole. Wird dieses Signal empfangen, während bereits ein Herunterfahren läuft, wird statt des „besonders sicheren Herunterfahrens“ ein „sofortiges Herunterfahren“ ausgelöst. In PgBouncer-Versionen vor 1.23.0 löste dieses Signal ein „sofortiges Herunterfahren“ aus.

SIGINT

Sicheres Herunterfahren. Entspricht SHUTDOWN WAIT_FOR_SERVERS an der Konsole. Wird dieses Signal empfangen, während bereits ein Herunterfahren läuft, wird statt des „sicheren Herunterfahrens“ ein „sofortiges Herunterfahren“ ausgelöst.

SIGQUIT

Sofortiges Herunterfahren. Entspricht SHUTDOWN an der Konsole.

SIGUSR1

Entspricht PAUSE an der Konsole.

SIGUSR2

Entspricht RESUME an der Konsole.

Libevent-Einstellungen

Aus der Libevent-Dokumentation:

Es ist möglich, die Unterstützung für epoll, kqueue, devpoll, poll oder select zu deaktivieren, indem die Umgebungsvariable EVENT_NOEPOLL, EVENT_NOKQUEUE, EVENT_NODEVPOLL, EVENT_NOPOLL oder EVENT_NOSELECT jeweils gesetzt wird.

Durch Setzen der Umgebungsvariablen EVENT_SHOW_METHOD zeigt libevent die verwendete Kernel-Benachrichtigungsmethode an.

Siehe auch

pgbouncer(5) – Handbuchseite mit Beschreibungen der Konfigurationseinstellungen

https://www.pgbouncer.org/

3 - PgBouncer kompilieren und installieren

Kompilieren

Für das Kompilieren von PgBouncer werden einige Komponenten benötigt:

• GNU Make 3.81+
• Libevent 2.0+
• pkg-config
• OpenSSL 1.0.1+ für TLS-Unterstützung
• (optional) c-ares als Alternative zu evdns von Libevent
• (optional) LDAP-Bibliotheken
• (optional) PAM-Bibliotheken

Wenn alle Abhängigkeiten installiert sind, führen Sie folgende Befehle aus:

$ ./configure --prefix=/usr/local
$ make
$ make install

Wenn Sie PgBouncer direkt aus dem Git-Repository oder für Windows kompilieren, beachten Sie die entsprechenden Anleitungen weiter unten.

Unterstützung für DNS-Abfragen

PgBouncer löst Hostnamen beim Verbindungsaufbau auf und nicht nur einmal beim Einlesen der Konfiguration. Dafür ist eine asynchrone DNS-Implementierung erforderlich. Die folgende Tabelle zeigt die unterstützten Backends und die Reihenfolge, in der sie geprüft werden:

1. EDNS0 ist erforderlich, wenn einem Hostnamen mehr als 8 Adressen zugeordnet sind.
2. Eine SOA-Abfrage ist erforderlich, um Hostnamen bei einer Änderung der Zonen-Seriennummer erneut zu prüfen.
3. Um EDNS0 zu aktivieren, fügen Sie options edns0 zu /etc/resolv.conf hinzu.

c-ares ist die Implementierung mit dem größten Funktionsumfang und wird für die meisten Einsatzbereiche sowie für die Erstellung von Binärpaketen empfohlen (sofern eine ausreichend neue Version verfügbar ist). Das in Libevent integrierte evdns eignet sich unter Beachtung der genannten Einschränkungen ebenfalls für viele Einsatzbereiche. Die übrigen Backends sind inzwischen weitgehend veraltet und werden kaum noch getestet.

Standardmäßig wird c-ares verwendet, sofern es gefunden wird. Der Einsatz lässt sich mit configure --with-cares erzwingen oder mit --without-cares deaktivieren. Wenn c-ares nicht verwendet wird (weil es nicht gefunden oder deaktiviert wurde), kommt Libevent zum Einsatz. Mit --disable-evdns deaktivieren Sie evdns von Libevent; anschließend wird auf eine libc-basierte Implementierung zurückgegriffen.

PAM-Authentifizierung

Um die PAM-Authentifizierung zu aktivieren, rufen Sie ./configure mit der Option --with-pam auf (standardmäßig deaktiviert). Nach dem Kompilieren mit PAM-Unterstützung steht der neue globale Authentifizierungstyp pam zur Verfügung, mit dem Benutzer über PAM authentifiziert werden können.

LDAP-Authentifizierung

Um die LDAP-Authentifizierung zu aktivieren, rufen Sie ./configure mit der Option --with-ldap auf (standardmäßig deaktiviert). Nach dem Kompilieren mit LDAP-Unterstützung steht der neue globale Authentifizierungstyp ldap zur Verfügung, mit dem Benutzer über LDAP authentifiziert werden können.

systemd-Integration

Um die systemd-Integration zu aktivieren, rufen Sie configure mit der Option --with-systemd auf. Damit lassen sich Type=notify (oder Type=notify-reload, wenn Sie systemd 253 oder neuer verwenden) sowie die Socket-Aktivierung nutzen. Beispiele finden Sie in etc/pgbouncer.service und etc/pgbouncer.socket.

Aus dem Git-Repository kompilieren

Wenn Sie PgBouncer direkt aus dem Git-Repository kompilieren, müssen Sie die Header- und Konfigurationsdateien generieren, bevor Sie configure ausführen können:

$ git clone https://github.com/pgbouncer/pgbouncer.git
$ cd pgbouncer
$ ./autogen.sh
$ ./configure
$ make
$ make install

Standardmäßig werden alle Dateien unter /usr/local installiert. Sie können für configure eine oder mehrere Befehlszeilenoptionen angeben. Führen Sie ./configure --help aus, um die verfügbaren Optionen und die Umgebungsvariablen aufzulisten, mit denen sich die Konfiguration anpassen lässt.

Zusätzlich erforderliche Pakete: autoconf, automake, libtool, pandoc

Tests

Weitere Informationen zum Ausführen der Tests finden Sie in der Datei README.md im Testverzeichnis .

Kompilieren unter Windows

Die einzige unterstützte Build-Umgebung unter Windows ist MinGW. Cygwin und Visual $ANYTHING werden nicht unterstützt.

Führen Sie zum Kompilieren unter MinGW die üblichen Schritte aus:

$ ./configure
$ make

Für eine Cross-Kompilierung unter Unix verwenden Sie:

$ ./configure --host=i586-mingw32msvc

Die LDAP-Kompilierungsoption wird unter Windows derzeit nicht unterstützt.

Betrieb unter Windows

Der Aufruf über die Befehlszeile erfolgt wie üblich. Die Schalter -d (Daemon-Modus), -R (Neustart) und -u (Benutzerwechsel) funktionieren jedoch nicht.

Wenn Sie PgBouncer als Windows-Dienst ausführen möchten, legen Sie mit dem Parameter service_name einen Namen für den Dienst fest. Danach:

$ pgbouncer -regservice config.ini

Zum Deinstallieren des Dienstes:

$ pgbouncer -unregservice config.ini

Um das Windows-Ereignisprotokoll zu nutzen, setzen Sie syslog = 1 in der Konfigurationsdatei. Zuvor müssen Sie pgbevent.dll registrieren:

$ regsvr32 pgbevent.dll

Um die Registrierung aufzuheben, führen Sie folgenden Befehl aus:

$ regsvr32 /u pgbevent.dll

4 - Quellcode-Releases zum Download

PgBouncer 1.25

PgBouncer 1.24

PgBouncer 1.23

PgBouncer 1.22

PgBouncer 1.21

PgBouncer 1.20

PgBouncer 1.19

PgBouncer 1.18

PgBouncer 1.17

PgBouncer 1.16

PgBouncer 1.15

PgBouncer 1.14

PgBouncer 1.13

PgBouncer 1.12

PgBouncer 1.11

PgBouncer 1.10

PgBouncer 1.9

PgBouncer 1.8

PgBouncer 1.7

PgBouncer 1.6

PgBouncer 1.5

PgBouncer 1.4

PgBouncer 1.3

PgBouncer 1.2

PgBouncer 1.1

PgBouncer 1.0

Binärpakete

Viele Betriebssystemdistributionen stellen ein eigenes natives PgBouncer-Paket beziehungsweise einen Port bereit. Prüfen Sie daher zunächst, ob PgBouncer bereits für Ihr Betriebssystem verfügbar ist.

In den folgenden dedizierten Paketquellen sind unter Umständen neuere Versionen verfügbar als in den Repositories der jeweiligen Distribution:

• RPM: yum.PostgreSQL.org
• Deb: apt.PostgreSQL.org

5 - Community

Tutorials

• So konfigurieren Sie PgBouncer für Postgres Plus Standard Server

  Gute Übersicht über PgBouncer-Konzepte.

• Wozu dient das „Bouncing“?

  Beschreibt die Unterschiede zwischen den Pooling-Modi.

Support

• Projektseite auf GitHub

• Issue-Tracker auf GitHub

• PgBouncer-Themenbereich auf Stack Overflow

• Community-Diskussionen auf GitHub

6 - Häufig gestellte Fragen

Wie stelle ich eine Verbindung zu PgBouncer her?

PgBouncer verhält sich wie ein PostgreSQL-Server. Richten Sie Ihren Client daher einfach auf den PgBouncer-Port.

Wie lassen sich Abfragen auf mehrere Server verteilen?

PgBouncer bietet keine interne Multi-Host-Konfiguration. Die Verteilung ist jedoch mit externen Werkzeugen möglich:

1. DNS-Round-Robin. Hinterlegen Sie mehrere IP-Adressen für einen DNS-Namen. PgBouncer führt nicht bei jeder neuen Verbindung eine DNS-Abfrage durch. Stattdessen speichert es alle IP-Adressen im Cache und verteilt die Verbindungen intern per Round-Robin. Hinweis: Sind einem Namen mehr als 8 IP-Adressen zugeordnet, muss das DNS-Backend das EDNS0-Protokoll unterstützen. Einzelheiten finden Sie in der README-Datei.

2. Verwenden Sie einen Load-Balancer für TCP-Verbindungen. Sowohl LVS als auch HAProxy eignen sich dafür. Auf PgBouncer-Seite kann es sinnvoll sein, server_lifetime zu verkürzen und server_round_robin zu aktivieren: Standardmäßig werden inaktive Verbindungen nach dem LIFO-Prinzip wiederverwendet, was bei Lastverteilung ungünstig sein kann.

Wie lässt sich ein Failover durchführen?

PgBouncer bietet weder eine interne Failover-Host-Konfiguration noch eine entsprechende Erkennung. Ein Failover lässt sich mit externen Werkzeugen realisieren:

1. DNS-Neukonfiguration: Wenn die IP-Adresse geändert wird, auf die ein DNS-Name verweist, verbindet sich PgBouncer erneut mit dem neuen Server. Dieses Verhalten lässt sich über zwei Konfigurationsparameter steuern: dns_max_ttl legt die Gültigkeitsdauer eines Hostnamens fest; dns_zone_check_period bestimmt, wie häufig der SOA-Eintrag einer Zone auf Änderungen geprüft wird. Hat sich der SOA-Eintrag geändert, fragt PgBouncer alle Hostnamen dieser Zone erneut ab.

2. Tragen Sie einen neuen Host in die Konfiguration ein und lassen Sie PgBouncer sie neu laden: Senden Sie SIGHUP oder verwenden Sie den Befehl RELOAD in der Konsole. PgBouncer erkennt die geänderte Hostkonfiguration und verbindet sich mit dem neuen Server.

3. Verwenden Sie den Befehl RECONNECT. Er ist für Situationen vorgesehen, in denen sich keine der beiden vorherigen Optionen anwenden lässt, etwa wenn Sie den zuvor erwähnten HAProxy-Load-Balancer einsetzen, um Verbindungen hinter PgBouncer weiterzuleiten. RECONNECT öffnet einfach alle Serververbindungen neu. Führen Sie den Befehl aus, nachdem die andere Komponente ihre Routinginformationen geändert hat.

Wie lassen sich vorbereitete Anweisungen mit Session-Pooling verwenden?

Im Session-Pooling muss die Reset-Abfrage alte vorbereitete Anweisungen bereinigen. Hierzu kann server_reset_query = DISCARD ALL; oder zumindest DEALLOCATE ALL; verwendet werden.

Wie lassen sich vorbereitete Anweisungen mit Transaktions-Pooling verwenden?

Seit Version 1.21.0 kann PgBouncer vorbereitete Anweisungen im Transaktions-Pooling nachverfolgen und sicherstellen, dass sie bei Bedarf auf der zugeordneten Serververbindung vorbereitet werden. Um diese Funktion zu aktivieren, muss max_prepared_statements auf einen von null verschiedenen Wert gesetzt werden. Weitere Einzelheiten finden Sie in der Dokumentation zu max_prepared_statements .

Je nach verwendeter Version kann PHP/PDO mit der Unterstützung vorbereiteter Anweisungen durch PgBouncer inkompatibel sein (#991 ). PHP/PDO ist nur bei Verwendung von PHP 8.4+ und libpq 17 kompatibel. Für Installationen mit älteren Versionen empfiehlt sich daher ein Upgrade oder die Deaktivierung vorbereiteter Anweisungen auf Clientseite.

Vorbereitete Anweisungen in JDBC deaktivieren

Fügen Sie hierzu den Parameter prepareThreshold=0 zur Verbindungszeichenfolge hinzu.

Vorbereitete Anweisungen in PHP/PDO deaktivieren

Um serverseitig vorbereitete Anweisungen zu deaktivieren, setzen Sie das PDO-Attribut PDO::ATTR_EMULATE_PREPARES auf true — entweder beim Verbindungsaufbau:

$db = new PDO("dsn", "user", "pass", array(PDO::ATTR_EMULATE_PREPARES => true));

oder später:

$db->setAttribute(PDO::ATTR_EMULATE_PREPARES, true);

Wie aktualisiere ich PgBouncer, ohne Verbindungen zu unterbrechen?

Führen Sie einen Rolling Restart nach dem Verfahren im Dokumentationsabschnitt zu SHUTDOWN WAIT_FOR_CLIENTS durch.

Wie finde ich heraus, welcher Client welcher Serververbindung zugeordnet ist?

Verwenden Sie die Befehle SHOW CLIENTS und SHOW SERVERS in der Konsole.

1. Ordnen Sie mithilfe von ptr und link eine lokale Clientverbindung der Serververbindung zu.

2. Identifizieren Sie die vom Client ausgehende TCP-Verbindung anhand von addr und port der Clientverbindung.

3. Identifizieren Sie die zum Server führende TCP-Verbindung anhand von local_addr und local_port.

Soll PgBouncer auf dem Webserver oder dem Datenbankserver installiert werden?

Das hängt vom Einsatzszenario ab.

Eine Installation von PgBouncer auf dem Webserver ist sinnvoll, wenn kurzlebige Verbindungen genutzt werden, weil sie die Latenz beim Verbindungsaufbau minimiert. (TCP benötigt mehrere Paketumlaufzeiten, bevor eine Verbindung nutzbar ist.) Eine Installation von PgBouncer auf dem Datenbankserver eignet sich, wenn viele unterschiedliche Hosts (z. B. Webserver) darauf zugreifen. Ihre Verbindungen können dann gemeinsam optimiert werden.

PgBouncer kann sowohl auf dem Webserver als auch auf dem Datenbankserver installiert werden. Nachteilig ist, dass jeder zusätzliche PgBouncer-Hop jeder Abfrage eine geringe Latenz hinzufügt.

Letztlich müssen Sie testen, welches Modell Ihre Leistungsanforderungen am besten erfüllt. Berücksichtigen Sie außerdem, wie sich die gewählte PgBouncer-Position auf das Failover Ihrer Anwendungen auswirkt, wenn ein Webserver beziehungsweise der Datenbankserver ausfällt.