Schritt-für-Schritt-Anleitung zur Einrichtung der PostgreSQL Streaming Replication

Richten Sie mit diesem Schritt-für-Schritt-Tutorial eine zuverlässige, hochverfügbare Streaming-Replikation in PostgreSQL ein. Erfahren Sie, wie Sie den primären Server mithilfe von `wal_level = replica` konfigurieren und `pg_hba.conf` aktualisieren. Wir beschreiben detailliert den Prozess des Klonens des Datenverzeichnisses mithilfe von `pg_basebackup -R` und überprüfen die Synchronisierung mithilfe von `pg_stat_replication`. Diese Anleitung gewährleistet, dass Ihre PostgreSQL-Umgebung mithilfe moderner Konfigurationspraktiken robuste Datenredundanz und Failover-Fähigkeiten erreicht.

45 Aufrufe

Schritt-für-Schritt-Anleitung zur Einrichtung der PostgreSQL-Streaming-Replikation

Streaming-Replikation ist der grundlegende Mechanismus zur Erreichung hoher Verfügbarkeit (HA) und Leseskalierbarkeit in PostgreSQL-Umgebungen. Durch die Konfiguration eines primären (Master-)Servers, der Write-Ahead Log (WAL)-Einträge kontinuierlich an einen oder mehrere Standby- (Replika-)Server streamt, stellen Sie die Datensynchronisation mit minimaler Verzögerung sicher.

Diese umfassende Anleitung führt Sie durch die wesentlichen Schritte zur Einrichtung einer robusten, asynchronen Streaming-Replikation. Wir behandeln die erforderlichen Konfigurationsänderungen sowohl auf dem primären als auch auf dem Standby-Server und nutzen moderne PostgreSQL-Funktionen wie pg_basebackup und Signaldateien für eine vereinfachte Einrichtung. Wenn Sie diesem Tutorial folgen, verfügen Sie über eine zuverlässige Grundlage für einen robusten PostgreSQL-Betrieb.

Voraussetzungen und Umgebungssetup

Stellen Sie vor Beginn sicher, dass die folgenden Voraussetzungen erfüllt sind. Diese Anleitung geht von zwei Servern aus, Primary und Standby, auf denen dieselbe Hauptversion von PostgreSQL läuft (Version 12 oder neuer wird empfohlen).

Server Rolle IP-Adresse (Beispiel)
Primary Quelle der Wahrheit 192.168.1.10
Standby Replika 192.168.1.11
  • Benutzer: Sie benötigen administrative Zugangsdaten (z. B. sudo oder den postgres-Systembenutzer) auf beiden Servern.
  • Netzwerk: Der Standby-Server muss sich mit dem Primary-Server über den PostgreSQL-Port (Standard 5432) verbinden können.

Schritt 1: Konfiguration des primären Servers

Der primäre Server muss so konfiguriert werden, dass er WAL-Dateien für die Replikation generiert und bereitstellt.

1.1 postgresql.conf ändern

Bearbeiten Sie die Hauptkonfigurationsdatei, die sich normalerweise im Datenverzeichnis befindet (z. B. /etc/postgresql/14/main/postgresql.conf), und setzen Sie die folgenden Parameter:

# Verbindungen von anderen Hosts zulassen
listen_addresses = '*'

# WAL-Level auf 'replica' oder höher setzen
wal_level = replica

# Maximale Anzahl gleichzeitiger Verbindungen von Standby-Servern
max_wal_senders = 5 

# Steuert die Anzahl der gleichzeitig aktiven Replika-Verbindungen
max_replication_slots = 5

# Erforderlich für schreibgeschützte Abfragen auf dem Standby (Hot Standby)
hot_standby = on

1.2 Dedizierten Replikationsbenutzer erstellen

Erstellen Sie aus Sicherheitsgründen einen speziellen Benutzer mit dem Attribut REPLICATION. Dieser Benutzer wird nur vom Standby-Server verwendet, um WAL-Einträge abzurufen.

# Mit PostgreSQL verbinden
psql -c "CREATE USER replica_user REPLICATION ENCRYPTED PASSWORD 'SuperSecurePassword123';"

1.3 Client-Authentifizierung (pg_hba.conf) aktualisieren

Erlauben Sie dem Replikationsbenutzer von der IP-Adresse des Standby-Servers, sich mit der speziellen Pseudo-Datenbank replication zu verbinden.

# TYP  DATENBANK        BENUTZER            IP-ADRESSE                 METHODE
host    replication     replica_user    192.168.1.11/32         md5

1.4 Primären Server neu starten

Wenden Sie die Änderungen an, indem Sie den PostgreSQL-Dienst neu starten:

sudo systemctl restart postgresql

Schritt 2: Vorbereitung des Standby-Servers

Stellen Sie vor dem Klonen der Daten sicher, dass der PostgreSQL-Dienst des Standby-Servers gestoppt ist und sein vorhandenes Datenverzeichnis gelöscht wurde.

2.1 Standby-PostgreSQL-Dienst stoppen

sudo systemctl stop postgresql

2.2 Datenverzeichnis löschen

Warnung: Dieser Schritt löscht dauerhaft alle Daten, die sich derzeit im Datenverzeichnis des Standby-Servers befinden. Bestätigen Sie den Pfad vor der Ausführung.

# Beispielpfad für PG 14
PG_DATA=/var/lib/postgresql/14/main

sudo rm -rf $PG_DATA/*

2.3 Daten mit pg_basebackup klonen

Verwenden Sie pg_basebackup, um eine exakte Kopie des Datenverzeichnisses des primären Servers zu erstellen. Das Flag -R ist entscheidend, da es automatisch die notwendigen Konfigurationsdateien (standby.signal und primary_conninfo) für die Streaming-Replikation (PostgreSQL 12+) generiert.

Führen Sie diesen Befehl auf dem Standby-Server aus:

PG_DATA=/var/lib/postgresql/14/main

sudo -u postgres pg_basebackup -h 192.168.1.10 -D $PG_DATA -U replica_user -P -v -R
Option Beschreibung
-h Hostname/IP-Adresse des primären Servers.
-D Lokaler Pfad zum Datenverzeichnis.
-U Name des Replikationsbenutzers (replica_user).
-P Fortschritt anzeigen.
-v Ausführliche Ausgabe.
-R Eine Replikationskonfigurationsdatei automatisch erstellen.

Schritt 3: Standby konfigurieren und starten

3.1 Standby-Konfiguration überprüfen

Wenn Sie das Flag -R in Schritt 2.3 verwendet haben, hat pg_basebackup eine Datei standby.signal erstellt und die Einstellung primary_conninfo populär gemacht, normalerweise in einer generierten Konfigurationsdatei namens postgresql.auto.conf im Datenverzeichnis.

Überprüfen Sie den Inhalt des primary_conninfo-Strings. Er sollte ähnlich wie dieser aussehen (prüfen Sie in $PG_DATA/postgresql.auto.conf):

primary_conninfo = 'host=192.168.1.10 user=replica_user password=SuperSecurePassword123 application_name=standby_node'

Tipp: Stellen Sie sicher, dass das Passwort in primary_conninfo enthalten ist oder dass Sie zertifikatbasierte Authentifizierung verwenden. Wenn pg_hba.conf mit trust oder cert verwendet wird, kann das Passwort weggelassen werden.

3.2 Standby-Dienst starten

Da die erforderliche Signaldatei (standby.signal) im Datenverzeichnis vorhanden ist, startet der Dienst im schreibgeschützten Standby-Modus und versucht sofort, eine Verbindung zum primären Server herzustellen.

sudo systemctl start postgresql

Schritt 4: Streaming-Replikation überprüfen

Nachdem Sie den Standby-Server gestartet haben, müssen Sie bestätigen, dass die Verbindung aktiv ist und die Datensynchronisation stattfindet.

4.1 Überprüfung auf dem primären Server

Verbinden Sie sich mit dem primären Server und fragen Sie die Ansicht pg_stat_replication ab. Sie sollten eine Zeile sehen, die die Verbindung vom Standby-Server repräsentiert.

psql -c "SELECT client_addr, state, sync_state, sent_lsn, write_lsn, flush_lsn FROM pg_stat_replication;"

Erwartete Ausgabe (Schlüsselfelder):

  • client_addr: Sollte der IP-Adresse des Standby-Servers entsprechen (z. B. 192.168.1.11).
  • state: Sollte streaming sein. Wenn startup oder catching up angezeigt wird, warten Sie einen Moment. Wenn walsender startet, sind Sie nahe dran.
  • sync_state: Sollte async sein (für Standard-Asynchron-Replikation).

4.2 Testen der Datensynchronisation

Um den Datenfluss zu bestätigen, führen Sie eine Änderung auf dem primären Server aus und prüfen Sie sofort, ob sie auf dem Standby-Server vorhanden ist.

Auf dem primären Server:

CREATE TABLE replication_test (id serial primary key, message text);
INSERT INTO replication_test (message) VALUES ('Data synchronized successfully');

Auf dem Standby (schreibgeschützt):

-- Dies muss ohne Fehler erfolgreich sein
psql -c "SELECT * FROM replication_test;"

Wenn die Daten auf dem Standby-Server sichtbar sind, ist die Streaming-Replikation erfolgreich konfiguriert und aktiv.

Best Practices und Fehlerbehebung

Dauerhafte Verbindung: Replikations-Slots

Obwohl optional, werden Replikations-Slots dringend empfohlen. Ein Replikations-Slot stellt sicher, dass der primäre Server keine WAL-Segmente vorzeitig verwirft, die der Standby-Server benötigt, selbst wenn der Standby vorübergehend die Verbindung verliert.

Auf dem primären Server:

SELECT * FROM pg_create_physical_replication_slot('standby_slot_name');

Aktualisieren Sie dann primary_conninfo auf dem Standby, um diesen Slot zu nutzen:

primary_conninfo = 'host=192.168.1.10 user=replica_user ... application_name=standby_node **slotname=standby_slot_name**'

Warnung: Replikations-Slots erfordern sorgfältige Überwachung. Wenn ein Standby-Server für längere Zeit ausfällt, können die angesammelten WAL-Dateien, die durch den Slot geschützt sind, dazu führen, dass der Festplattenspeicher des primären Servers schnell voll wird.

Fehlerbehebung bei häufigen Problemen

Problem Mögliche Ursache Lösung
Standby bleibt in starting stecken Netzwerk-Firewall oder falsche pg_hba.conf auf dem primären Server. Überprüfen Sie, ob Port 5432 geöffnet ist; stellen Sie sicher, dass der Eintrag in pg_hba.conf mit der IP-Adresse und dem Benutzer des Standby-Servers übereinstimmt.
pg_basebackup schlägt mit Authentifizierungsfehler fehl Falsches Passwort oder fehlender Host-Eintrag in pg_hba.conf. Überprüfen Sie das Passwort für replica_user; stellen Sie sicher, dass die primäre Datenbank nach der Änderung von pg_hba.conf neu gestartet wurde.
Standby ist schreibgeschützt Dies ist das erwartete Verhalten. Das Vorhandensein von standby.signal zwingt den Server in den Wiederherstellungsmodus.

Fazit

Die Einrichtung der Streaming-Replikation ist ein wichtiger Schritt beim Aufbau einer ausfallsicheren PostgreSQL-Architektur. Indem Sie diese Schritte befolgen, haben Sie erfolgreich ein primär-standby-Paar konfiguriert, das eine kontinuierliche Datensynchronisation gewährleistet und die Hochverfügbarkeitsfähigkeiten Ihres Systems erheblich verbessert. Der nächste logische Schritt ist die Integration einer Überwachungslösung und eines Failover-Mechanismus (wie Patroni oder Repmgr), um die HA-Einrichtung vollständig zu automatisieren.