Verwalten von Hochverfügbarkeit in PostgreSQL – Teil II:Replication Manager

Stellen Sie PostgreSQL in der Cloud bereit und möchten Ihre Optionen zum Erreichen von Hochverfügbarkeit verstehen? In unserem vorherigen Blogbeitrag „Managing High Availability in PostgreSQL – Part I“ haben wir die Möglichkeiten und Funktionsweise von PostgreSQL Automatic Failover (PAF) von ClusterLabs besprochen. In Teil II stellen wir Ihnen ein alternatives Open-Source-Tool vor, Replication Manager von 2ndQuadrant, dicht gefolgt von Teil III, in dem wir uns mit unserer dritten Alternative, Patroni by Zalando, befassen.

• Verwalten von Hochverfügbarkeit in PostgreSQL – Teil I:Automatisches PostgreSQL-Failover
• Verwalten von Hochverfügbarkeit in PostgreSQL – Teil III:Patroni

Replikationsmanager (repmgr)

repmgr ist eine Open-Source-Tool-Suite, die von 2ndQuadrant entwickelt wurde, um die Replikation und das Failover Ihrer PostgreSQL-Cluster zu verwalten. Es bietet die Tools zum Einrichten, Konfigurieren, Verwalten und Überwachen der Replikation von PostgreSQL und ermöglicht es Ihnen außerdem, manuelle Switchover- und Failover-Aufgaben mit dem Dienstprogramm repmgr durchzuführen. Dieses kostenlose Tool unterstützt und verbessert die integrierte Streaming-Replikation von PostgreSQL.

Replication Manager bietet zwei Haupttools zum Verwalten der Replikation und des Failover von PostgreSQL.

repmgr

• Ein Dienstprogramm für die Befehlszeilenschnittstelle, mit dem Sie verschiedene Verwaltungsaufgaben ausführen können.
• repmgr ermöglicht es Ihnen, Standby-Server einzurichten, Standbys hochzustufen, eine Umschaltung durchzuführen und den Status Ihres PostgreSQL-Clusters zu überwachen.
• Es bietet auch Probelaufoptionen für fast alle Verwaltungsbefehle.

repmgrd

Dies ist der Daemon, der:

• Überwacht aktiv die PostgreSQL-Cluster und führt die erforderlichen Aktionen basierend auf dem Status des Clusters durch.
• Führt ein automatisches Failover durch, falls der primäre Knoten ausfällt, indem der geeignetste Standby-Knoten als neuer primärer Knoten hochgestuft wird.
• Bietet eine Option zum Überwachen und Speichern der Daten bezüglich der Replikationsleistung.
• Benachrichtigt durch Aufrufen der Benutzerskripts für registrierte Ereignisse.

Wie es funktioniert

repmrg verwaltet nicht nur die Replikation von PostgreSQL-Clustern, sondern verfügt auch über Funktionen zum Einrichten der Standby-Server für die Replikation. Nach der Erstinstallation müssen wir Änderungen an der repmgr-Konfigurationsdatei (repmgr.conf) mit den erforderlichen Details auf jedem Server vornehmen. Wenn ein Server konfiguriert wird, muss er mit dem Befehl repmgr primary/standby register bei repmgr registriert werden. Zuerst wird der primäre Knoten eingerichtet und registriert. Anschließend werden Standby-Server erstellt und mit dem Befehl repmgr standby clone konfiguriert, der den PostgreSQL-Standby-Knoten von einem anderen PostgreSQL-Server klont.

Replication Manager nutzt die PostgreSQL-Erweiterungsfunktion und erstellt sein eigenes Schema in der Cluster-Datenbank, um die Cluster-bezogenen Informationen zu speichern. Die Installation der Erweiterung und die Erstellung des Schemas erfolgt während der Registrierung des primären Servers mit repmgr. Sobald die Einrichtung abgeschlossen ist, können manuelle Verwaltungsvorgänge wie Heraufstufen, Folgen, Umschalten usw. mit dem Dienstprogramm repmgr durchgeführt werden. Für den Switchover-Betrieb muss passwortloses SSH zwischen den Knoten eingerichtet werden.

Automatisches Failover kann mit repmgrd eingerichtet werden. repmgrd erfordert, dass eine gemeinsam genutzte Bibliothek „repmgr“ zum Zeitpunkt des Starts des PostgreSQL-Servers geladen wird. Der Bibliotheksname sollte in den shared_preload_libraries erwähnt werden Konfigurationsparameter in der Datei postgresql.conf. Damit repmgrd funktioniert, failover=automatic Parameter müssen in der Datei repmgr.conf festgelegt werden. Sobald alle diese Parameter festgelegt sind, beginnt der repmgrd-Daemon mit der aktiven Überwachung des Clusters. Wenn im primären Knoten ein Fehler auftritt, versucht er mehrmals, die Verbindung wiederherzustellen. Wenn alle Versuche, sich mit dem Primärserver zu verbinden, fehlschlagen, wird der geeignetste Standby-Server per Wahl als neuer Primärserver von repmgrd ausgewählt.

repmgr unterstützt auch Ereignisbenachrichtigungen. Es verfügt über eine Reihe vordefinierter Ereignisse und speichert jedes Auftreten dieser Ereignisse in der Tabelle repmgr.events. repmgr ermöglicht die Weitergabe von Ereignisbenachrichtigungen an ein benutzerdefiniertes Programm oder Skript, das weitere Maßnahmen ergreifen kann, z. B. das Senden einer E-Mail oder das Auslösen einer Warnung. Dies geschieht durch Setzen des event_notification_command Parameter in repmgr.conf.

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

repmgr bewältigt Split-Brain-Szenarien mithilfe des Standorts -Parameter, wobei jeder Knoten den Standortparameter basierend auf dem Rechenzentrum angeben sollte, in dem er platziert ist. Im Falle einer Netzwerkaufteilung stellt repmgr die Heraufstufung des Knotens sicher, der sich am selben Standort wie der primäre befindet. Wenn es an diesem Ort keinen Knoten findet, wird es keinen Knoten an irgendeinem Ort heraufstufen.

Es behandelt auch die Netzwerkisolation im Falle einer geraden Anzahl von Servern in einem Cluster. Dies erfolgt mithilfe eines zusätzlichen Knotens, der Zeugenserver genannt wird. Der Witness-Server ist ein Knoten, der nur für die Mehrheitsstimmenzählung berücksichtigt wird. Es wird keine PostgreSQL-Installation auf diesem Server geben und daher keine Rolle bei der Replikation spielen.

Gibt es Einrichtungsanforderungen?

• repmgr erfordert eine dedizierte Datenbank und einen Benutzer mit Superuser-Rechten. Es besteht jedoch auch die Möglichkeit, einen Superuser bereitzustellen, wenn Sie dem Superuser keinen Zugriff auf den repmgr-Benutzer gewähren möchten.
• Wenn Sie möchten, dass repmgr Konfigurationsdateien kopiert, die sich außerhalb des PostgreSQL-Datenverzeichnisses befinden, und/oder die Switchover-Funktionalität testen möchten, benötigen Sie außerdem passwortlose SSH-Verbindungen zwischen beiden Servern und rsync sollte installiert sein.
• Wenn Sie beabsichtigen, andere dienstbasierte Befehle als pg_ctl (das standardmäßig von repmgr verwendet wird) zum Starten, Stoppen, Neuladen und Neustarten zu verwenden, können Sie diese in repmgr angeben Konfigurationsdatei (repmgr.conf).
• Die grundlegenden Konfigurationsparameter, die in der repmgr-Konfigurationsdatei erforderlich sind, lauten wie folgt:
  

  node_id (int) – Eine eindeutige ganze Zahl größer als Null, die den Knoten identifiziert. node_name (string) – Eine willkürliche (aber eindeutige) Zeichenfolge, die den Hostnamen des Servers oder eine andere eindeutig mit dem Server verknüpfte Kennung verwendet, wird empfohlen, um Verwirrung zu vermeiden. conninfo (Zeichenfolge) – Datenbankverbindungsinformationen als Conninfo-String. Alle Server im Cluster müssen sich mit dieser Zeichenfolge mit dem lokalen Knoten verbinden können. Datenverzeichnis (Zeichenfolge) – Das Datenverzeichnis des Knotens. Dies wird von repmgr benötigt, um Vorgänge auszuführen, wenn die PostgreSQL-Instanz nicht ausgeführt wird und es keine andere Möglichkeit gibt, das Datenverzeichnis zu ermitteln.

Repmgr-Vorteile

• Repmgr bietet Dienstprogramme, die dabei helfen, primäre und Standby-Knoten einzurichten und die Replikation zu konfigurieren.
• Es verwendet keine zusätzlichen Ports für die Kommunikation. Wenn Sie eine Umschaltung durchführen möchten, muss nur dann passwortloses SSH konfiguriert werden.
• Benachrichtigt durch Aufrufen der Benutzerskripts für die registrierten Ereignisse.
• Führt bei einem Ausfall des Primärservers ein automatisches Failover durch.

Repmgr-Nachteile

• repmgr erkennt nicht, ob der Standby-Server mit einem unbekannten oder nicht vorhandenen Knoten in der Wiederherstellungskonfiguration falsch konfiguriert ist. Der Knoten wird als Standby angezeigt, auch wenn er ohne Verbindung zum primären/kaskadierenden Standby-Knoten ausgeführt wird.
• Der Status eines anderen Knotens kann nicht von einem Knoten abgerufen werden, auf dem der PostgreSQL-Dienst ausgefallen ist. Daher bietet es keine verteilte Steuerungslösung.
• Es behandelt nicht die Wiederherstellung des Zustands einzelner Knoten.

Verwalten von Hochverfügbarkeit in #PostgreSQL – Teil II:Open-Source-Repmgr-Tool Click To Tweet

Hochverfügbarkeitstestszenarien

Wir haben ein paar Tests zur PostgreSQL-Hochverfügbarkeitsverwaltung mit repmgr durchgeführt. Alle diese Tests wurden ausgeführt, während die Anwendung lief 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

Master-/Primärserver-Tests

Netzwerkisolationstests

Schlussfolgerung

repmgr bietet mehrere Befehle zum Einrichten und Überwachen der PostgreSQL-Replikation. Es ist funktionsreich und erleichtert auch die Arbeit des Datenbankadministrators (DBA). Es ist jedoch kein vollwertiges Verwaltungstool für Hochverfügbarkeit, da es die Ressourcen nicht verwaltet. Es ist ein manueller Eingriff erforderlich, um sicherzustellen, dass sich die Ressource in einem ordnungsgemäßen Zustand befindet.

Also haben wir in diesem Beitrag die Fähigkeiten und Funktionsweisen von Replication Manager von 2ndQuadrant besprochen. In unserem nächsten Beitrag werden wir dieselben Hochverfügbarkeitsaspekte mit Patroni by Zalando besprechen. Für Benutzer, die ihre Hochverfügbarkeit in der Cloud automatisieren möchten, sehen Sie sich unsere vollständig verwalteten Lösungen für PostgreSQL auf Azure und PostgreSQL auf AWS an.