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

Verwalten von Hochverfügbarkeit in PostgreSQL – Teil III:Patroni

In unseren vorherigen Blogbeiträgen haben wir die Möglichkeiten und Funktionsweise von PostgreSQL Automatic Failover (PAF) von Cluster Labs und Replication Manager (repmgr) von 2ndQuadrant besprochen. Im letzten Beitrag dieser Serie werden wir die letzte Lösung, Patroni von Zalando, überprüfen und alle drei am Ende vergleichen, damit Sie bestimmen können, welches Hochverfügbarkeits-Framework für Ihre PostgreSQL-Hosting-Bereitstellung am besten geeignet ist.

  • Verwalten von Hochverfügbarkeit in PostgreSQL – Teil I:Automatisches PostgreSQL-Failover
  • Verwalten von Hochverfügbarkeit in PostgreSQL – Teil II:Replication Manager

Patroni für PostgreSQL

Patroni entstand als Fork von Governor, einem Projekt von Compose. Es handelt sich um eine in Python geschriebene Open-Source-Tool-Suite zur Verwaltung der Hochverfügbarkeit von PostgreSQL-Clustern. Anstatt ein eigenes Konsistenzprotokoll zu erstellen, nutzt Patroni auf intelligente Weise das Konsistenzmodell, das von einem Distributed Configuration Store (DCS) bereitgestellt wird. Es unterstützt auch andere DCS-Lösungen wie Zookeeper, etcd, Consul und Kubernetes.

Patroni stellt die End-to-End-Einrichtung von PostgreSQL HA-Clustern sicher, einschließlich Streaming-Replikation. Es unterstützt verschiedene Möglichkeiten zum Erstellen eines Standby-Knotens und funktioniert wie eine Vorlage, die an Ihre Anforderungen angepasst werden kann.

Dieses funktionsreiche Tool stellt seine Funktionalität über REST-APIs und auch über ein Befehlszeilendienstprogramm namens patronictl bereit. Es unterstützt die Integration mit HAProxy, indem es seine Zustandsprüfungs-APIs verwendet, um den Lastausgleich zu handhaben.

Patroni unterstützt auch Ereignisbenachrichtigungen mithilfe von Rückrufen, d. h. Skripts, die durch bestimmte Aktionen ausgelöst werden. Es ermöglicht Benutzern, beliebige Wartungsaktionen durchzuführen, indem es eine Pause/Fortsetzen-Funktion bereitstellt. Die Watchdog-Unterstützungsfunktion macht das Framework noch robuster.

Wie es funktioniert

Zunächst müssen PostgreSQL- und Patroni-Binärdateien installiert werden. Sobald dies erledigt ist, müssen Sie auch eine HA-DCS-Konfiguration einrichten. Alle erforderlichen Konfigurationen zum Bootstrap des Clusters müssen in der yaml-Konfigurationsdatei angegeben werden, und Patroni verwendet diese Datei für die Initialisierung. Auf dem ersten Knoten initialisiert Patroni die Datenbank, erhält die Leitersperre von DCS und stellt sicher, dass der Knoten als Master ausgeführt wird.

Der nächste Schritt ist das Hinzufügen von Standby-Knoten, für die Patroni mehrere Optionen bereitstellt. Standardmäßig verwendet Patroni pg_basebackup zum Erstellen des Standby-Knotens und unterstützt auch benutzerdefinierte Methoden wie WAL-E, pgBackRest, Barman und andere für die Erstellung des Standby-Knotens. Patroni macht es sehr einfach, einen Standby-Knoten hinzuzufügen, und übernimmt alle Bootstrapping-Aufgaben und die Einrichtung Ihrer Streaming-Replikation.

Hochverfügbarkeit in #PostgreSQL verwalten – Teil III:Patroni vs. PAF vs. repmgrClick To Tweet

Sobald Ihr Cluster eingerichtet ist, überwacht Patroni den Cluster aktiv und stellt sicher, dass er sich in einem fehlerfreien Zustand befindet. Der Master-Knoten erneuert die Leader-Sperre alle ttl Sekunde(n) (Standard:30 Sekunden). Wenn der Master-Knoten die Leader-Sperre nicht erneuern kann, löst Patroni eine Wahl aus, und der Knoten, der die Leader-Sperre erhält, wird zum neuen Master gewählt.

Wie geht es mit dem Split-Brain-Szenario um?

In einem verteilten System spielt der Konsens eine wichtige Rolle bei der Bestimmung der Konsistenz, und Patroni verwendet DCS, um einen Konsens zu erzielen. Nur der Knoten, der die Leader-Sperre hält, kann der Master sein, und die Leader-Sperre wird über DCS erhalten. Wenn der Master-Knoten die Leader-Sperre nicht hält, wird er sofort von Patroni herabgestuft, um als Standby zu laufen. Auf diese Weise kann zu jedem Zeitpunkt nur ein Master im System laufen.

Gibt es Einrichtungsanforderungen?

  • Patroni benötigt Python 2.7 und höher.
  • Das DCS und sein spezifisches Python-Modul müssen installiert sein. Zu Testzwecken kann DCS auf denselben Knoten installiert werden, auf denen PostgreSQL ausgeführt wird. In der Produktion muss DCS jedoch auf separaten Knoten installiert werden.
  • Die Yaml-Konfigurationsdatei muss mit diesen allgemeinen Konfigurationseinstellungen vorhanden sein:

    Global/Universal
    Dazu gehören Konfigurationen wie der Name des Hosts (Name), der für den Cluster eindeutig sein muss, der Name des Clusters (Bereich) und der Pfad zum Speichern der Konfiguration in DCS (Namespace).

    Protokollieren
    Patroni-spezifische Protokolleinstellungen einschließlich Ebene, Format, Dateinummer, Dateigröße usw.

    Bootstrap-Konfiguration
    Dies ist die globale Konfiguration für einen Cluster, der in DCS geschrieben wird. Diese Konfigurationsparameter können mit Hilfe von Patroni-APIs oder direkt in DCS geändert werden. Die Bootstrap-Konfiguration umfasst Standby-Erstellungsmethoden, initdb-Parameter, Post-Initialisierungsskript usw. Sie enthält auch Timeout-Konfiguration, Parameter zur Entscheidung über die Verwendung von PostgreSQL-Funktionen wie Replikationsslots , synchroner Modus usw. Dieser Abschnitt wird nach der Initialisierung des neuen Clusters in ///config eines bestimmten Konfigurationsspeichers geschrieben.

    PostgreSQL
    Dieser Abschnitt enthält die PostgreSQL-spezifischen Parameter wie Authentifizierung, Verzeichnispfade für Daten, Binärdateien und Konfiguration, Listen-IP-Adresse usw.

    REST-API
    Dieser Abschnitt enthält die Patroni-spezifische Konfiguration in Bezug auf REST-APIs wie Listenadresse, Authentifizierung, SSL usw.

    Konsul
    Einstellungen speziell für Consul DCS.

    Etcd
    Etcd DCS-spezifische Einstellungen.

    Aussteller
    Spezifische Einstellungen für Aussteller-DCS.

    Kubernetes
    Kubernetes DCS-spezifische Einstellungen.

    ZooKeeper
    ZooKeeper DCS-spezifische Einstellungen.

    Wachhund
    Watchdog-spezifische Einstellungen.

Patroni-Profis

  • Patroni ermöglicht die End-to-End-Einrichtung des Clusters.
  • Unterstützt REST-APIs und HAproxy-Integration.
  • Unterstützt Ereignisbenachrichtigungen über Rückrufskripte, die durch bestimmte Aktionen ausgelöst werden.
  • Nutzt DCS für Konsens.

Patroni-Nachteile

  • Patroni wird die Fehlkonfiguration eines Standby mit einem unbekannten oder nicht vorhandenen Knoten in der Wiederherstellungskonfiguration nicht erkennen. Der Knoten wird auch dann als Slave angezeigt, wenn der Standby-Knoten ohne Verbindung zum Master/kaskadierenden Standby-Knoten ausgeführt wird.
  • Der Benutzer muss sich um die Einrichtung, Verwaltung und Aktualisierung der DCS-Software kümmern.
  • Erfordert, dass mehrere Ports für die Komponentenkommunikation geöffnet sind:
    • REST-API-Port für Patroni
    • Mindestens 2 Ports für DCS

Hochverfügbarkeitstestszenarien

Wir haben einige Tests zur PostgreSQL HA-Verwaltung mit Patroni durchgeführt. Alle diese Tests wurden durchgeführt, während die Anwendung ausgeführt wurde und Daten in die PostgreSQL-Datenbank einfügte. Die Anwendung wurde unter Verwendung des PostgreSQL Java JDBC-Treibers geschrieben, der die Verbindungs-Failover-Funktion nutzt.

Standby-Server-Tests

Sl. Nein Testszenario Beobachtung
1 Beenden Sie den PostgreSQL-Prozess Patroni hat den PostgreSQL-Prozess wieder in den laufenden Zustand gebracht.

  • Es gab keine Unterbrechung der Writer-Anwendung.
2 Beenden Sie den PostgreSQL-Prozess Patroni hat den PostgreSQL-Prozess wieder in den laufenden Zustand gebracht.

  • Es gab keine Unterbrechung der Writer-Anwendung.
3 Starten Sie den Server neu Patroni muss nach dem Neustart gestartet werden, es sei denn, es wurde so konfiguriert, dass es beim Neustart nicht startet. Sobald Patroni gestartet wurde, startete es den PostgreSQL-Prozess und richtete die Standby-Konfiguration ein.

  • Es gab keine Unterbrechung der Writer-Anwendung.
4 Beenden Sie den Patroni-Prozess
  • Der PostgreSQL-Prozess wurde nicht gestoppt.
  • patronische Liste hat diesen Server nicht angezeigt.
  • Es gab keine Unterbrechung der Writer-Anwendung.

Im Wesentlichen müssen Sie also den Zustand des Patroni-Prozesses überwachen – andernfalls führt dies später zu Problemen.

Master-/Primärserver-Tests

Sl. Nein Testszenario Beobachtung
1 Beenden Sie den PostgreSQL-Prozess Patroni hat den PostgreSQL-Prozess wieder in den laufenden Zustand versetzt. Patroni, das auf diesem Knoten ausgeführt wird, hatte eine primäre Sperre und daher wurde die Wahl nicht ausgelöst.

  • Es gab eine Ausfallzeit in der Writer-Anwendung.
2 Halten Sie den PostgreSQL-Prozess an und bringen Sie ihn sofort nach Ablauf der Zustandsprüfung zurück Patroni hat den PostgreSQL-Prozess wieder in den laufenden Zustand versetzt. Patroni, das auf diesem Knoten ausgeführt wird, hatte eine primäre Sperre und daher wurde die Wahl nicht ausgelöst.

  • Es gab eine Ausfallzeit in der Writer-Anwendung.
3 Starten Sie den Server neu Failover ist aufgetreten und einer der Standby-Server wurde nach Erhalt der Sperre zum neuen Master gewählt. Als Patroni auf dem alten Master gestartet wurde, brachte es den alten Master zurück und führte pg_rewind aus und begann, dem neuen master.T

zu folgen
  • Es gab eine Ausfallzeit in der Writer-Anwendung.
4 Patroni-Prozess stoppen/beenden
  • Einer der Standby-Server erlangte die DCS-Sperre und wurde zum Master, indem er sich selbst beförderte.
  • Der alte Master lief noch und führte zu einem Multi-Master-Szenario. Die Bewerbung wurde noch an den alten Meister geschrieben.
  • Sobald Patroni auf dem alten Master gestartet wurde, spulte es den alten Master zurück (use_pg_rewind auf true gesetzt war) auf die neue Master-Timeline und lsn und begann, dem neuen Master zu folgen.

Wie Sie oben sehen können, ist es sehr wichtig, den Zustand des Patroni-Prozesses auf dem Master zu überwachen. Andernfalls kann es zu einem Multi-Master-Szenario und potenziellem Datenverlust kommen.

Netzwerkisolationstests

Sl. Nein Testszenario Beobachtung
1 Isolieren Sie den Master-Server im Netzwerk von anderen Servern DCS-Kommunikation wurde für Master-Knoten blockiert.

  • PostgreSQL wurde auf dem Master-Server heruntergestuft.
  • Ein neuer Meister wurde in der Mehrheitspartition gewählt.
  • Es gab eine Ausfallzeit in der Writer-Anwendung.
2 Netzwerkisolieren Sie den Standby-Server von anderen Servern Die DCS-Kommunikation wurde für den Standby-Knoten blockiert.

  • Der PostgreSQL-Dienst wurde ausgeführt, der Knoten wurde jedoch nicht für Wahlen berücksichtigt.
  • Es gab keine Unterbrechung in der Writer-Anwendung.

Was ist das beste PostgreSQL-HA-Framework?

Patroni ist ein wertvolles Tool für PostgreSQL-Datenbankadministratoren (DBAs), da es die End-to-End-Einrichtung und -Überwachung eines PostgreSQL-Clusters durchführt. Die Flexibilität bei der Auswahl von DCS und Standby-Erstellung ist ein Vorteil für den Endbenutzer, da er die Methode wählen kann, mit der er vertraut ist.

REST-APIs, HaProxy-Integration, Watchdog-Unterstützung, Callbacks und seine funktionsreiche Verwaltung machen Patroni zur besten Lösung für die PostgreSQL-HA-Verwaltung.

PostgreSQL-HA-Framework-Tests:PAF vs. repmgr vs. Patroni

Unten finden Sie eine umfassende Tabelle mit den Ergebnissen aller Tests, die wir an allen drei Frameworks durchgeführt haben – PostgreSQL Automatic Failover (PAF), Replication Manager (repmgr) und Patroni.

Standby-Server-Tests

Testszenario Automatisches PostgreSQL-Failover (PAF) Replication Manager (repmgr) Patroni
Beenden Sie den PostgreSQL-Prozess Pacemaker hat den PostgreSQL-Prozess wieder in den laufenden Zustand versetzt.

  • Es gab keine Unterbrechung der Writer-Anwendung.
 Der Standby-Server wurde als ausgefallen markiert. Es war ein manueller Eingriff erforderlich, um den PostgreSQL-Prozess erneut zu starten.

  • Es gab keine Unterbrechung der Writer-Anwendung.
 Patroni hat den PostgreSQL-Prozess wieder in den laufenden Zustand versetzt.

  • Es gab keine Unterbrechung der Writer-Anwendung.
Beenden Sie den PostgreSQL-Prozess Pacemaker hat den PostgreSQL-Prozess wieder in den laufenden Zustand versetzt.

  • Es gab keine Unterbrechung der Writer-Anwendung.
 Der Standby-Server wurde als ausgefallen markiert. Es war ein manueller Eingriff erforderlich, um den PostgreSQL-Prozess erneut zu starten.

  • Es gab keine Unterbrechung der Writer-Anwendung.
 Patroni hat den PostgreSQL-Prozess wieder in den laufenden Zustand versetzt.

  • Es gab keine Unterbrechung der Writer-Anwendung.
Starten Sie den Server neu Der Standby-Server wurde zunächst als offline gekennzeichnet. Sobald der Server nach dem Neustart gestartet wurde, wurde PostgreSQL von Pacemaker gestartet und der Server als online markiert. Wenn Fencing aktiviert war, wurde der Knoten nicht automatisch zum Cluster hinzugefügt.

  • Es gab keine Unterbrechung der Writer-Anwendung.
 Der Standby-Server wurde als ausgefallen markiert. Sobald der Server nach dem Neustart gestartet wurde, wurde PostgreSQL manuell gestartet und der Server als ausgeführt markiert.

  • Es gab keine Unterbrechung der Writer-Anwendung.
 Patroni muss nach dem Neustart gestartet werden, es sei denn, es ist so konfiguriert, dass es beim Neustart nicht startet. Sobald Patroni gestartet wurde, startete es den PostgreSQL-Prozess und richtete die Standby-Konfiguration ein.

  • Es gab keine Unterbrechung der Writer-Anwendung.
Beenden Sie den Framework-Agent-Prozess Agent:Herzschrittmacher

  • Der PostgreSQL-Prozess wurde gestoppt und als offline markiert.
  • Es gab keine Unterbrechung der Writer-Anwendung.
 Agent:repmgrd

  • Der Standby-Server wird nicht Teil der automatisierten Failover-Situation sein.
  • Es wurde festgestellt, dass der PostgreSQL-Dienst ausgeführt wird.
  • Es gab keine Unterbrechung der Writer-Anwendung.
 Agent:patroni

  • It did not stop the PostgreSQL process.
  • patronictl list did not display this server.
  • There was no disruption of the writer application.

Master/Primary Server Tests

Test Scenario PostgreSQL Automatic Failover (PAF) Replication Manager (repmgr) Patroni
Kill the PostgreSQL process Pacemaker brought the PostgreSQL process back to running state. Primary got recovered within the threshold time and hence election was not triggered.

  • There was downtime in the writer application.
 repmgrd started health check for primary server connection on all standby servers for a fixed interval. When all retries failed, an election was triggered on all the standby servers. As a result of the election, the standby which had the latest received LSN got promoted. The standby servers which lost the election will wait for the notification from the new master node and will follow it once they receive the notification.Manual intervention was required to start the postgreSQL process again.

  • There was downtime in the writer application.
 Patroni brought the PostgreSQL process back to running state. Patroni running on that node had primary lock and hence election was not triggered.

  • There was downtime in the writer application.
Stop the PostgreSQL process and bring it back immediately after health check expiry Pacemaker brought the PostgreSQL process back to running state. Primary got recovered within the threshold time and hence election was not triggered.

  • There was downtime in the writer application.
 repmgrd started health check for primary server connections on all standby servers for a fixed interval. When all the retries failed, an election was triggered on all the standby nodes. However, the newly elected master didn’t notify the existing standby servers since the old master was back.Cluster was left in an indeterminate state and manual intervention was required.

  • There was downtime in the writer application.
 Patroni brought the PostgreSQL process back to running state. Patroni running on that node had primary lock and hence election was not triggered.

  • There was downtime in the writer application.
Reboot the server Election was triggered by Pacemaker after the threshold time for which master was not available. The most eligible standby server was promoted as the new master. Once the old master came up after reboot, it was added back to the cluster as a standby. If fencing was enabled, then node wouldn’t have been added automatically to cluster.

  • There was downtime in the writer application.
 repmgrd started election when master connection health check failed on all standby servers. The eligible standby was promoted. When this server came back, it didn’t join the cluster and was marked failed. repmgr node rejoin command was run to add the server back to the cluster.

  • There was downtime in the writer application.
 Failover happened and one of the standby servers was elected as the new master after obtaining the lock. When Patroni was started on the old master, it brought back the old master up and performed pg_rewind and started following the new master.

  • There was downtime in the writer application.
Stop the framework agent process Agent:pacemaker

  • The PostgreSQL process was stopped and it was marked offline.
  • Election was triggered and new master was elected.
  • There was downtime in writer application.
 Agent:repmgrd

  • The primary server will not be part of the automated failover situation.
  • PostgreSQL service was found to be running.
  • There was no disruption in writer application.
 Agent:patroni

  • One of the standby servers acquired the DCS lock and became the master by promoting itself.
  • The old master was still running and it led to multi-master scenario. The application was still writing to the old master.
  • Once Patroni was started on the old master, it rewound the old master (use_pg_rewind was set to true) to the new master timeline and lsn and started following the new master.

Network Isolation Tests

Test Scenario PostgreSQL Automatic Failover (PAF) Replication Manager (repmgr) Patroni
Network isolate the master server from other servers (split brain scenario) Corosync traffic was blocked on the master server.

  • PostgreSQL service was turned off and master server was marked offline due to quorum policy.
  • A new master was elected in the majority partition.
  • There was a downtime in the writer application.
 All servers have the same value for location in repmgr configuration:

  • repmgrd started election when master connection health check failed on all standby servers.
  • The eligible standby was promoted, but the PostgreSQL process was still running on the old master node.
  • There were two nodes running as master. Manual intervention was required after the network isolation was corrected.

The standby servers have the same value for location but the primary had a different value for location in repmgr configuration:

  • repmgrd started election when master connection health check failed on all standby servers.
  • But, there was no new master elected since the standby servers had location different from that of the primary.
  • repmgrd went into degrade monitoring mode. PostgreSQL was running on all the nodes and there was only one master in the cluster.
 DCS communication was blocked for master node.

  • PostgreSQL was demoted on the master server.
  • A new master was elected in the majority partition.
  • There was a downtime in the writer application.
Network-isolate the standby server from other servers Corosync traffic was blocked on the standby server.

  • The server was marked offline and PostgreSQL service was turned off due to quorum policy.
  • There was no disruption in the writer application.
  • repmgrd went into degrade monitoring mode.
  • The PostgreSQL process was still running on the standby node.
  • Manual intervention was required after the network isolation was corrected.
 DCS communication was blocked for the standby node.

  • The PostgreSQL service was running, however, the node was not considered for elections.
  • There was no disruption in the writer application.