Konzept on PIG.CENTER

Funktionen

Mon, 01 Jan 0001 00:00:00 +0000

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.

Patroni 4.1.5 Dokumentation

Mon, 01 Jan 0001 00:00:00 +0000

Warnung

Betrieb von Patroni auf Systemen mit begrenztem Arbeitsspeicher und Python 3.11+

Wenn Sie Patroni auf einem System mit strengen Speichergrenzen betreiben, beispielsweise mit vm.overcommit_memory=2 (für PostgreSQL empfohlen), und Python 3.11 oder neuer verwenden, kann unerwartetes Verhalten auftreten:

Patroni scheint ordnungsgemäß zu funktionieren
PostgreSQL läuft weiter
Die REST API von Patroni reagiert nicht mehr
Das Betriebssystem meldet, dass Patroni auf dem REST API-Port lauscht
Die Patroni-Protokolle erscheinen normal; einmalig können jedoch folgende Meldungen auftreten: Exception ignored in thread started by: <object repr() failed>, MemoryError
Die Kernel-Protokolle können Meldungen wie not enough memory for the allocation enthalten

Dieses Verhalten wird durch einen Fehler in Python 3.11+ verursacht. Bei strengen Speichergrenzen kann der Start eines neuen Threads auf unbestimmte Zeit hängen bleiben, wenn nicht genügend freier Arbeitsspeicher verfügbar ist.

Dokumentation zu PgBouncer 1.25.2

Mon, 01 Jan 0001 00:00:00 +0000

PgBouncer ist ein Verbindungspooler für PostgreSQL. Eine beliebige Client-Anwendung kann sich mit PgBouncer verbinden, als handele es sich um einen PostgreSQL-Server. PgBouncer stellt dann eine Verbindung zum eigentlichen Server her oder verwendet eine bereits bestehende Verbindung.

PgBouncer soll die Leistungseinbußen verringern, die beim Aufbau neuer Verbindungen zu PostgreSQL entstehen.

Damit die Transaktionssemantik beim Verbindungs-Pooling gewahrt bleibt, unterstützt PgBouncer mehrere Pooling-Modi, die sich in der Dauer der Verbindungszuweisung unterscheiden:

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.

Dokumentation zu pgBadger 13.2

Mon, 01 Jan 0001 00:00:00 +0000

pgBadger ist ein schnelles, eigenständiges und in Perl geschriebenes Analyseprogramm für PostgreSQL-Protokolle. Es liest PostgreSQL- oder PgBouncer-Protokolle und erzeugt detaillierte Ausgaben als HTML, Text, Binärdaten, JSON oder Roh-CSV. Die HTML-Berichte sind in sich geschlossen, interaktiv und zoombar; zur Anzeige genügt ein Webbrowser.

Warum pgBadger

pgBadger ist für große Protokolle und den betrieblichen Einsatz konzipiert:

ein einziges Perl-Programm ohne obligatorische Module außerhalb der Perl-Standardbibliothek;
automatische Erkennung von stderr, syslog, csvlog, jsonlog, RDS, Cloud SQL, logplex, Redshift und PgBouncer-Eingabe;
direktes Lesen lokaler Dateien, der Standardeingabe, entfernter Dateien über SSH sowie von HTTP-, FTP- oder SFTP-URLs;
mit gzip, bzip2, lz4, xz, zip oder zstd komprimierte Eingaben;
parallele Analyse einer großen Datei oder vieler kleiner Dateien;
tägliche und wöchentliche inkrementelle Berichte sowie monatliche Berichte auf Abruf;
Filter nach Zeit, Datenbank, Benutzer, Client, Anwendung, Prozess, Sitzung und Abfragemuster.

Was die Berichte enthalten

Die PostgreSQL-Berichte umfassen:

etcd 3.7 Dokumentation

Mon, 01 Jan 0001 00:00:00 +0000

etcd ist ein verteiltes Schlüssel-Wert-System mit starker Konsistenz. Diese Anleitungen behandeln die Installation und den Betrieb von etcd, die Entwicklung von Anwendungen mit seinen APIs, den internen Aufbau, Leistungsmessungen sowie Upgrades und Downgrades von Clustern innerhalb der Versionsreihe 3.7.

Beginnen Sie mit dem Schnellstart für einen lokalen Cluster mit einem einzelnen Mitglied, der Installation für unterstützte Installationswege oder dem Betriebshandbuch für Produktionsumgebungen.

Community

Mon, 01 Jan 0001 00:00:00 +0000

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

Watchdog-Unterstützung

Mon, 01 Jan 0001 00:00:00 +0000

Das gleichzeitige Ausführen mehrerer PostgreSQL-Server als primäre Server kann zu Datenverlusten aufgrund von unterschiedlichen Zeitlinien führen. Diese Situation wird auch als “Split-Brain”-Problem bezeichnet. Um das Split-Brain-Problem zu vermeiden, muss Patroni sicherstellen, dass PostgreSQL keine Transaktionsbestätigungen akzeptiert, nachdem der Schlüssel für den primären Server in der DCS abgelaufen ist. Unter normalen Umständen versucht Patroni, dies durch das Stoppen von PostgreSQL zu erreichen, falls der Update-Vorgang für den primären Schlüssel aus irgendeinem Grund fehlschlägt. Dies kann jedoch aus verschiedenen Gründen fehlschlagen:

Integration mit anderen Tools

Mon, 01 Jan 0001 00:00:00 +0000

Patroni kann sich in andere Tools in Ihrer Umgebung integrieren. In diesem Abschnitt finden Sie eine Liste von Beispielen, die zwar keine vollständige Liste darstellen, aber Ihnen Ideen geben können, wie Patroni mit anderen Tools zusammenarbeiten kann.

Barman

Patroni liefert eine Anwendung namens patroni_barman, die über Logik verfügt, um mit pg-backup-api zu kommunizieren, sodass Sie Barman-Operationen entfernt durchführen können.

Diese Anwendung verfügt derzeit über mehrere Unterkommandos: recover und config-switch.

Sicherheitshinweise

Mon, 01 Jan 0001 00:00:00 +0000

Ein Patroni-Cluster verfügt über zwei Schnittstellen, die vor unbefugtem Zugriff geschützt werden müssen: das verteilte Konfigurationsspeicher (DCS) und die Patroni REST-API.

Schutz des DCS

Sowohl Patroni als auch patronictl speichern und abrufen Daten von/zum DCS.

Obwohl der DCS keine sensiblen Informationen enthält, ermöglicht er die Änderung einiger Konfigurationen von Patroni/Postgres. Daher sollte der DCS selbst daher als erstes geschützt werden.

Die Details zum Schutz hängen vom verwendeten Typ des DCS ab. Die Authentifizierungs- und Verschlüsselungsparameter (Token/Basic-Auth/Client-Zertifikate) für die unterstützten DCS-Typen sind in den Einstellungen beschrieben.

HA-Multi-Datacenter

Mon, 01 Jan 0001 00:00:00 +0000

Die Hochverfügbarkeit eines PostgreSQL-Clusters, der in mehreren Rechenzentren bereitgestellt wird, basiert auf Replikation, die synchron oder asynchron erfolgen kann (siehe Replikationsmodi ).

In beiden Fällen ist es wichtig, die folgenden Konzepte klar zu verstehen:

PostgreSQL kann nur als primärer oder sekundärer Knoten betrieben werden, wenn es den Schlüssel besitzt und diesen aktualisieren kann.
Sie sollten eine ungerade Anzahl von etcd-, ZooKeeper- oder Consul-Knoten betreiben: 3 oder 5!

Synchrones Replikation

Um einen mehrere Rechenzentrum (DC) umfassenden Cluster zu haben, der automatisch einen Ausfall einer Zone tolerieren kann, sind mindestens 3 erforderlich.