Einrichten von Failover-Slots in PostgreSQL-17

PostgreSQL 17 führt Failover-Slots ein, die die Einrichtung von Hochverfügbarkeitsumgebungen verbessern. Ein Replikationsslot gewährleistet, dass die Daten während der Replikation zwischen den Knoten zuverlässig und konsistent bleiben, während ein Failover-Slot die Konsistenz zwischen den Knoten sicherstellt, insbesondere während und nach einem Failover.

Failover-Slots sind ein leistungsstarkes Feature, das sicherstellt, dass die logische Replikation nahtlos fortgesetzt werden kann, selbst nach einem Failover zu einem Standby-Server. Die Verwendung von Failover-Slots ermöglicht es, dass logische Replikationsslots automatisch zwischen Primär- und Standby-Knoten synchronisiert werden, wodurch die Ausfallzeit erheblich reduziert wird und manuelle Eingriffe während eines Failovers vermieden werden können.

Dieser Leitfaden führt Sie durch die Einrichtung eines Hochverfügbarkeitsclusters für PostgreSQL unter Verwendung des neuen Features für Failover-Slots. Am Ende haben Sie eine robuste Replikationsumgebung eingerichtet, die in der Lage ist, einen Failover nahtlos zu bewältigen.

Warum Failover-Slots aus historischer Sicht wichtig sind

Herausforderungen in PostgreSQL 15

• Replikationsslots an den Primärknoten gebunden: In PostgreSQL 15 wurden Replikationsslots nur auf dem Primärserver erstellt. Alle logischen Replikationsslots gingen verloren, wenn der Primärserver ausfiel, was zu erheblichen Replikationsverzögerungen und Datenverlust führte.
• Manuelles Failover-Management: Während Failover-Szenarien erstellten Administratoren manuell Replikationsslots auf dem neuen Primärserver, was die Komplexität erhöhte, Fehler einführte und die Ausfallzeit verlängerte.
• Keine Slot-Synchronisierung: Standby-Server wussten nichts über logische Replikationsslots auf dem Primärserver. Diese mangelnde Synchronisierung führte dazu, dass Replikationsströme bei einem Failover komplett zurückgesetzt wurden.

Verbesserungen in PostgreSQL 16

Minimales logisches Decodieren

PostgreSQL 16 führte eine Funktion namens minimalen logischen Decodierung auf Standby-Servern ein:

• Minimales Decodieren auf Standby: Dies ermöglichte es Standby-Servern, WAL-Protokolle zu decodieren, um sich auf die logische Replikation vorzubereiten und vorgewärmte Slots zur Verfügung zu stellen, falls ein Failover auftritt.
• Schnellerer Failover: Durch das vorherige Decodieren von WAL-Änderungen auf dem Standby war es möglich, die Replikationsverzögerung beim Hochstufen eines Standbys zum Primärserver zu reduzieren. Es war jedoch immer noch erforderlich, einige manuelle Konfigurationen vorzunehmen, um einen reibungslosen Failover zu gewährleisten.

PostgreSQL 17: Die Spielveränderung – Failover-Slots

• Failover-Slots: Die Einführung von Failover-Slots in PostgreSQL 17 beseitigt die Notwendigkeit manueller Eingriffe, indem logische Replikationsslots automatisch zwischen Primär- und Standby-Servern synchronisiert werden.
• Automatische Synchronisierung: Der neue Slot-Synchronisierungs-Worker stellt sicher, dass Failover-aktivierte Slots (Failover = true) immer synchronisiert sind, selbst wenn der Primärknoten aktiv ist.
• Nahtloser Übergang: Bei einem Failover kann der Standby-Server die Rolle des Primärservers übernehmen, ohne dass Replikationsslots verloren gehen, was null Datenverlust und kontinuierliche Replikation gewährleistet.

Erstellen eines Hochverfügbarkeitsclusters mit Failover-Slots

In diesem Abschnitt zeigen wir Ihnen, wie Sie einen PostgreSQL-Hochverfügbarkeitscluster mit Failover-Slots erstellen. In unserem Beispiel verwenden wir die folgenden Knoten:

1. KnotenA (Primärserver)
2. KnotenB (Physischer Standby)
3. KnotenC (Logischer Abonnent)

Voraussetzungen

Bevor wir beginnen, stellen Sie sicher, dass Sie:

• PostgreSQL 17 auf allen drei Knoten installiert haben.
• Passwortlosen SSH-Zugriff zwischen jedem Knoten.
• Ein grundlegendes Verständnis von PostgreSQL, PostgreSQL-Replikation und PostgreSQL Konfigurationsdateien.

Schritt 1: Konfiguration des Primärknotens (KnotenA)

1.1 Initialisiere den Cluster auf NodeA

Nach der Installation von PostgreSQL auf dem primären Knoten, initialisiere den Cluster; du kannst die folgenden Befehle verwenden:

mkdir -p /home/pgedge/nodeA

​

initdb -D /home/pgedge/nodeA --no-locale -E UTF8 

​

pg_ctl -D /home/pgedge/nodeA -l /home/pgedge/logs/nodeA.log start 

1.2 Konfiguriere die Replikation in der postgresql.conf-Datei

Nach der Initialisierung des Clusters bearbeite die postgresql.conf-Datei, die standardmäßig unter /home/pgedge/nodeA/postgresql.conf zu finden ist. Setze die folgenden Parameterwerte:

wal_level = logical

​

max_replication_slots = 10

​

max_wal_senders = 10

​

synchronous_standby_names = '*'

​

synchronized_standby_slots = 'sb1_slot'

​

port = 5432

1.3 Aktualisiere die pg_hba.conf-Datei, um Replikationszugriff zu erlauben

Die pg_hba.conf-Datei verwaltet die Client-Authentifizierung für den PostgreSQL-Server. Füge den folgenden Eintrag zu /home/pgedge/nodeA/pg_hba.conf hinzu, um den Zugriff für einen Replikationsbenutzer zu gewährleisten:

host replication replicator 127.0.0.1/32 md5

Dann lade die Konfiguration neu:

pg_ctl -D /home/pgedge/nodeA reload 

1.4 Erstelle einen Replikationsbenutzer

Logge dich dann in PostgreSQL ein und erstelle den Replikationsbenutzer:

psql -d postgres -p 5432 

CREATE ROLE replicator WITH REPLICATION LOGIN PASSWORD 'replicator_password';

1.5 Erstelle eine Tabelle und richte eine Publikation ein

Nächster Schritt ist, eine Tabelle zu erstellen und eine zugehörige Publikation einzurichten:

CREATE TABLE foo (c1 INT PRIMARY KEY);

​

GRANT SELECT ON foo TO replicator;

​

CREATE PUBLICATION mypub FOR TABLE foo;

Schritt 2: Konfiguration des physischen Standbys (NodeB)

2.1 Initialisiere NodeB

Nach der Installation von PostgreSQL, initialisiere NodeB:

mkdir -p /home/pgedge/nodeB 

​

initdb -D /home/pgedge/nodeB --no-locale -E UTF8 

​

pg_ctl -D /home/pgedge/nodeB -l /home/pgedge/logs/nodeB.log start

2.1 Erstelle ein Basis-Backup

Verwende dann pg_basebackup, um ein Backup des Clusters zu erstellen:

mkdir -p /home/pgedge/nodeB 

​

pg_basebackup -D /home/pgedge/nodeB -R -X stream -P -h localhost -p 5432 -U replicator

2.2 Konfiguriere postgresql.conf auf Node-B

Ändern Sie die Datei postgresql.conf (befindet sich in /home/pgedge/nodeB/postgresql.conf) und setzen Sie:

port = 5433

​

primary_conninfo = 'host=localhost port=5432 user=replicator password=replicator_password dbname=postgres application_name=sb1_slot'

​

primary_slot_name = 'sb1_slot'

​

hot_standby_feedback = on

​

sync_replication_slots = on

2.3 Aktivieren Sie die Failover-Slot-Synchronisierung

Verwenden Sie den psql-Client, um sich bei NodeB anzumelden:

psql -d postgres -p 5433 

Verwenden Sie dann die folgenden Anweisungen, um die Replikation für NodeB zu konfigurieren:

ALTER SYSTEM SET sync_replication_slots = on;

​

ALTER SYSTEM SET hot_standby_feedback = on;

​

ALTER SYSTEM SET synchronized_standby_slots = 'sb1_slot';

Beenden Sie den psql-Client und starten Sie NodeB neu:

pg_ctl -D /home/pgedge/nodeB restart 

2.4 Überprüfen Sie die Slot-Synchronisierung

Verbinden Sie sich dann erneut mit NodeB mit psql und überprüfen Sie, ob die Slots synchronisiert sind:

SELECT slot_name, failover, synced FROM pg_replication_slots;

Schritt 3: Einrichten des logischen Abonnenten (NodeC)

3.1 Initialisieren Sie den Cluster und konfigurieren Sie NodeC

Nach der Installation von PostgreSQL initialisieren Sie den Cluster; Sie können die folgenden Befehle verwenden:

mkdir -p /home/pgedge/nodeC

​

initdb -D /home/pgedge/nodeC --no-locale -E UTF8

Bearbeiten Sie dann die Datei /home/pgedge/nodeC/postgresql.conf und setzen Sie die folgenden Parameterwerte:

wal_level = logical

​

max_replication_slots = 10

​

max_wal_senders = 10

​

sync_replication_slots = on

​

port = 5444

​

After editing the configuration file, start NodeC:

​

pg_ctl -D /home/pgedge/nodeC -l /home/pgedge/logs/nodeC.log start

3.2 Erstellen Sie ein Abonnement auf NodeC

Verwenden Sie den folgenden Befehl, um auf NodeC ein Abonnement zu erstellen:

CREATE SUBSCRIPTION foosub CONNECTION 'dbname=postgres host=localhost port=5432 user=replicator password=replicator_password' PUBLICATION mypub WITH (failover = true);

Schritt 4: Failover simulieren und Kontinuität sicherstellen

Sie können die folgenden Befehle verwenden, um ein Failover zu simulieren und zu bestätigen, dass die Replikation fortgesetzt wird und die Datenintegrität erhalten bleibt.

4.1 Failover simulieren

Verwenden Sie die folgenden Befehle, um einen Ausfall von NodeA zu simulieren, gefolgt von der Beförderung von Standby zu Primary von NodeB:

pg_ctl -D /home/pgedge/nodeA stop

​

pg_ctl -D /home/pgedge/nodeB promote

4.2 Aktualisieren Sie das Abonnement auf NodeC

Nach der Promotion von NodeB, melden Sie sich bei NodeC an und aktualisieren Sie die Verbindung, um widerzuspiegeln, dass NodeB jetzt der primäre Knoten ist:

ALTER SUBSCRIPTION foosub DISABLE;

​

ALTER SUBSCRIPTION foosub CONNECTION 'dbname=postgres host=localhost port=5433 user=replicator password=replicator_password';

​

ALTER SUBSCRIPTION foosub ENABLE;

4.3 Verifizieren der Datenkontinuität

Um die Replikation zu testen, verwenden Sie psql, um sich bei Node-B (jetzt der primäre Knoten) anzumelden:

INSERT INTO foo VALUES (3), (4);

Überprüfen Sie die Replikation auf Node-C:

SELECT * FROM foo;

Fazit

Die Failover-Slot-Funktion von PostgreSQL 17 ermöglicht nahtloses Failover in logischen Replikationsumgebungen. Wenn Sie die in diesem Leitfaden beschriebenen Schritte befolgen, können Sie einen hochverfügbaren Cluster erstellen, der einen unterbrechungsfreien Datenfluss gewährleistet, selbst während eines Ausfalls des primären Servers.

Durch die Optimierung der Konfigurationen und die Nutzung der neuen Funktionen von PostgreSQL 17 können Sie eine widerstandsfähige und effiziente Datenbankinfrastruktur für Ihre geschäftskritischen Anwendungen schaffen.