Verwalten der PostgreSQL-Hochverfügbarkeit – Teil I:Automatisches PostgreSQL-Failover

Die Verwaltung von Hochverfügbarkeit (HA) in Ihrem PostgreSQL-Hosting ist ein sehr wichtiges Thema, um sicherzustellen, dass Ihre Datenbankbereitstellungscluster eine außergewöhnliche Betriebszeit und eine starke Betriebsleistung aufrechterhalten, damit Ihre Daten Ihrer Anwendung immer zur Verfügung stehen. In einem früheren Blogbeitrag haben wir Ihnen die Konfiguration von Hochverfügbarkeit für PostgreSQL mithilfe von Streaming-Replikation vorgestellt, und jetzt zeigen wir Ihnen, wie Sie Hochverfügbarkeit auf Clientseite am besten verwalten.

Es stehen mehrere Tools zum Verwalten der Hochverfügbarkeit (HA) Ihrer PostgreSQL-Bereitstellungscluster mithilfe von Streaming-Replikation zur Verfügung. Diese Lösungen bieten automatische Failover-Funktionen, überwachen Verfügbarkeit und Systemstatus, Replikation, Benutzerverwaltung und andere nützliche Verwaltungsaufgaben für Anwendungsfälle für Postgres-Datenbanken. Einige der bekanntesten Open-Source-Lösungen sind:

1. Automatisches PostgreSQL-Failover von ClusterLabs

2. Replication Manager for PostgreSQL Clusters von repmgr (2ndQuadrant)

3. Patroni von Zalando

Jedes Tool bietet seine eigene Methode zur Verwaltung der Hochverfügbarkeits-PostgreSQL-Cluster. In unserer dreiteiligen Beitragsserie zu HA für PostgreSQL geben wir einen Überblick, die Voraussetzungen sowie die Arbeits- und Testergebnisse für jedes dieser drei Tools. Hier in Teil 1 tauchen wir tief in die PAF-Lösung von ClusterLabs ein.

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

Wie man Hochverfügbarkeit für Ihre PostgreSQL-Datenbank verwaltet?

PostgreSQL Automatic Failover (PAF) ist eine Hochverfügbarkeits-Verwaltungslösung für PostgreSQL von ClusterLabs. Es verwendet die synchrone Postgres-Replikation, um sicherzustellen, dass zum Zeitpunkt des Failover-Vorgangs keine Daten verloren gehen. Es nutzt den beliebten, branchenüblichen Pacemaker- und Corosync-Stack. Mit Pacemaker- und Corosync-Anwendungen zusammen können Sie PostgreSQL-Datenbankfehler im System erkennen und entsprechend handeln.

Pacemaker ist ein Dienst, der in der Lage ist, viele Ressourcen zu verwalten, und tut dies mit Hilfe seiner Ressourcen-Agents. Ressourcenagenten sind dann dafür verantwortlich, mit einer bestimmten Ressource umzugehen, wie sie sich verhalten sollten, und Pacemaker über ihre Ergebnisse zu informieren.

Ihre Ressourcen-Agent-Implementierung muss der Open Cluster Framework (OCF)-Spezifikation entsprechen. Diese Spezifikation definiert das Verhalten von Ressourcenagenten und die Implementierung von Methoden wie Stoppen, Starten, Heraufstufen, Herabstufen und Interaktion mit Pacemaker.

PAF ist ein in Perl geschriebener OCF-Ressourcenagent für Postgres. Sobald Ihr Datenbank-Cluster mit interner Streaming-Replikation erstellt wurde, kann PAF Pacemaker den aktuellen Status der PostgreSQL-Instanz auf jedem der Knoten der Datenbanken anzeigen:Master, Slave, gestoppt, aufholen, Load Balancer usw.

So funktioniert das automatische Postgres-Failover

PAF kommuniziert mit Pacemaker bezüglich des Clusterstatus und überwacht die Funktionsweise der PostgreSQL-Datenbank. Im Falle eines Ausfalls informiert es Pacemaker, und wenn keine Chance besteht, dass der aktuelle Master wiederhergestellt wird, löst es eine Wahl zwischen einem der aktuellen Standby-Datenbankserver aus. Wenn der robuste Pacemaker vorhanden ist, führt Postgres Automatic Failover Verwaltungsaktionen wie Starten, Stoppen, Überwachen und Failover auf allen Knoten der Postgres-Datenbanken durch.

Verwalten von Hochverfügbarkeit in PostgreSQL – Teil I:Automatisches Failover von ClusterLabsClick To Tweet

Automatisches PostgreSQL-Failover für Konfiguration mit hoher Verfügbarkeit (HA)

• PAF unterstützt PostgreSQL Version 9.3 und höher.
• PAF ist nicht für die PostgreSQL-Master/Standby-Erstellung oder deren Einrichtung verantwortlich – Sie müssen die Streaming-Replikation erstellen und einrichten, bevor Sie PAF verwenden.
• PAF bearbeitet keine Konfigurations- oder Einrichtungsanforderungen von PostgreSQL. Es erfordert jedoch, dass Datenbankbenutzer einige Voraussetzungen erfüllen, wie z. B.:
  • Slave muss als Hot Standby konfiguriert sein. Hot-Standby-Slave-Knoten können als schreibgeschützte Datenbanken abgefragt werden.
  • Eine Wiederherstellungsvorlagendatei (Standard:/recovery.conf.pcmk) muss mit den folgenden Parametern bereitgestellt werden:
    • standby_mode =ein
    • recovery_target_timeline =„neueste“
    • primary_conninfo Der Parameter „application_name“ muss definiert und wie in Pacemaker auf den Namen des lokalen Knotens gesetzt sein.
• PAF stellt mehrere Parameter bereit, die sich auf die Verwaltung einer Postgres-Ressource beziehen. Diese kann nach eigenen Wünschen konfiguriert werden. Unten sind die Parameter:
  • bindir: Speicherort der PostgreSQL-Binärdateien (Standard:/usr/bin)
  • pgdata: Speicherort der PGDATA Ihrer Instanz (Standard:/var/lib/pgsql/data)
  • Datenverzeichnis: Pfad zu dem in data_directory festgelegten Verzeichnis aus Ihrer postgresql.conf-Datei
  • pghost: das Socket-Verzeichnis oder die IP-Adresse, die verwendet werden soll, um sich mit der lokalen Instanz zu verbinden (Standard:/tmp)
  • pgport: der Port zur Verbindung mit der lokalen Instanz (Standard:5432)
  • recovery_template: die lokale Vorlage, die als Datei PGDATA/recovery.conf kopiert wird. Diese Vorlagendatei muss auf allen Knoten vorhanden sein (Standard:$PGDATA/recovery.conf.pcmk)
  • start_opts: Zusätzliche Argumente, die dem Postgres-Prozess beim Start gegeben werden. Siehe „postgres –help“ für verfügbare Optionen. Nützlich, wenn sich die Datei postgresql.conf nicht im Datenverzeichnis (PGDATA) befindet, zB:-c config_file=/etc/postgresql/9.3/main/postgresql.conf
  • system_user: der Systemeigentümer des Prozesses Ihrer Instanz (Standard:postgres)
  • maxlag: maximal zulässige Verzögerung auf einem Standby, bevor wir einen negativen Master-Score dafür festlegen

Profis für automatisches Postgres-Failover

• PAF bietet dem Benutzer eine kostenlose praktische Konfiguration und Einrichtung von PostgreSQL.
• PAF kann mit Knotenausfällen umgehen und Wahlen auslösen, wenn der Master ausfällt.
• Quorumverhalten kann in PAF erzwungen werden.
• Es wird eine vollständige Hochverfügbarkeits-(HA)-Datenbankverwaltungslösung für die Ressource bereitstellen, einschließlich Starten, Stoppen und Überwachen sowie Behandeln von Netzwerkisolationsszenarien.
• Es ist eine verteilte Lösung, die die Verwaltung eines beliebigen Knotens von einem anderen Knoten aus ermöglicht.

Nachteile des automatischen Postgres-Failovers

• PAF erkennt nicht, ob ein Standby-Knoten mit einem unbekannten oder nicht vorhandenen Knoten in der Wiederherstellungskonfiguration falsch konfiguriert ist. Knoten wird als Slave angezeigt, auch wenn Standby läuft, ohne sich mit dem Master/kaskadierenden Standby-Knoten zu verbinden.
• Erfordert die Öffnung eines zusätzlichen Ports (Standard 5405) für die Kommunikation der Pacemaker- und Corosync-Komponenten über UDP.
• Unterstützt keine NAT-basierte Konfiguration.
• Keine pg_rewind-Unterstützung.

Hochverfügbarkeit für PostgreSQL-Testszenarien

Wir haben einige Tests durchgeführt, um die Leistungsfähigkeit der PostgreSQL-Hochverfügbarkeitsverwaltung (ha) unter Verwendung von PAF in einigen Anwendungsfällen zu bestimmen. Alle diese Tests wurden ausgeführt, während die Anwendung lief und Daten in die PostgreSQL-Datenbank einfügte. Die Anwendung wurde mit PostgreSQL Java JDBC-Treiber geschrieben, der die Verbindungs-Failover-Funktion nutzt.

Standby-Server-Tests

Master-/Primärserver-Tests

Netzwerkisolationstests

Verschiedene Tests

Ist PAF die Lösung für PostgreSQL High Availability?

Das automatische Postgres-Failover bietet in vielen Anwendungsfällen mehrere Vorteile beim Umgang mit PostgreSQL-Hochverfügbarkeit (HA). PAF verwendet IP-Adressen-Failover, anstatt den Standby neu zu starten, um während eines Failover-Ereignisses eine Verbindung zum neuen Master herzustellen. Dies erweist sich in Szenarien als vorteilhaft, in denen der Benutzer die Standby-Knoten nicht neu starten möchte. PAF erfordert auch nur sehr wenige manuelle Eingriffe und verwaltet den Gesamtzustand aller Postgres-Datenbankressourcen. Der einzige Fall, in dem ein manuelles Eingreifen erforderlich ist, ist im Falle einer Abweichung der Zeitachsendaten, bei der der Benutzer sich für die Verwendung von pg_rewind entscheiden kann.

In Teil 1 haben wir die Fähigkeiten und Funktionsweisen von PostgreSQL Automatic Failover (PAF) von ClusterLabs besprochen, und in Teil 2 werden wir darüber sprechen dieselben Hochverfügbarkeitsaspekte mit dem Replication Manager für PostgreSQL-Cluster (repmgr) von 2ndQuadrant. Schauen Sie auf jeden Fall noch einmal nach Teil 3, wo wir auch Patroni von Zalando behandeln und alle drei Open-Source-Lösungen vergleichen, um Ihnen dabei zu helfen, die beste Lösung für Ihre Anwendung zu finden.

In Teil 1 des Blogs haben wir die Funktionen, Best Practices und Funktionsweisen von PAF von ClusterLabs besprochen, und in Teil 2 des Blogbeitrags werden wir das tun diskutieren dasselbe Thema über Hochverfügbarkeitsaspekte mit dem Replication Manager für Postgresql-Cluster (repmgr) von 2ndQuadrant. Schauen Sie auf jeden Fall noch einmal nach unserem Blogpost zu Teil 3, in dem wir auch über Patroni von Zalando berichten und alle drei Open-Source-Lösungen vergleichen, um Ihnen dabei zu helfen, die Best Practices und die ideale Lösung für Ihre Geschäftsanwendungen zu ermitteln.