PostgreSQL-Replikation meistern: Typen und Einrichtung erklärt

PostgreSQL-Replikation hält einen zweiten Server so nah am Primärserver, dass Sie Hardwareausfälle überstehen, Lese-Last verlagern oder eine kontrollierte Migration durchführen können. Wenn Ihre Datenbank eine Produktionsabhängigkeit ist, müssen Sie wissen, welches PostgreSQL-Replikationsmodell zu Ihrer Risikotoleranz passt, bevor ein Knoten ausfällt.

PostgreSQL bietet Ihnen zwei gängige Optionen: Streaming-Replikation und logische Replikation. Streaming-Replikation kopiert WAL auf der physischen Cluster-Ebene. Die logische Replikation sendet zeilenbasierte Änderungen ausgewählter Tabellen über Publikationen und Abonnements.

Warum PostgreSQL-Replikation wichtig ist

Replikation hilft bei vier alltäglichen Betriebsproblemen:

Hohe Verfügbarkeit: Wenn der Primärserver ausfällt, können Sie einen Standby-Server hochstufen und Anwendungen darauf umleiten.
Notfallwiederherstellung: Ein Standby-Server an einem anderen Standort kann Sie vor einem standortweiten Ausfall schützen.
Leseskalierung: Schreibgeschützte Abfragen können gegen heiße Standby-Server statt gegen den Schreib-Primärserver ausgeführt werden.
Migrationsunterstützung: Logische Replikation kann helfen, ausgewählte Tabellen zwischen PostgreSQL-Versionen oder Datenbank-Layouts zu verschieben.

Replikation ist kein Backup-Ersatz. Ein Fehler, eine fehlerhafte Migration oder ein versehentliches DELETE können sich schnell replizieren. Behalten Sie getestete Backups und Point-in-Time-Recovery neben der Replikation.

Streaming-Replikation (physische Replikation)

Streaming-Replikation ist die häufigste und grundlegendste Form der Replikation in PostgreSQL. Sie funktioniert, indem Write-Ahead-Log (WAL)-Datensätze vom Primärserver an einen oder mehrere Replikate gesendet werden. Diese WAL-Datensätze repräsentieren jede Änderung an der Datenbank. Die Replikate wenden diese WAL-Datensätze dann auf ihre eigenen Datendateien an und stellen so sicher, dass sie mit dem Primärserver konsistent bleiben.

Synchrone vs. asynchrone Streaming-Replikation

Synchrone Replikation lässt den Primärserver auf ein oder mehrere synchrone Standby-Server warten, bevor er einen Commit an den Client meldet. Das genaue Sicherheitsniveau hängt von synchronous_commit ab; zum Beispiel unterscheidet sich das Warten auf das Schreiben von WAL vom Warten auf dessen Wiedergabe. Sie erhalten einen stärkeren Schutz gegen den Verlust bestätigter Commits, aber jeder Commit hängt jetzt von der Replikat- und Netzwerklatenz ab.

Asynchrone Replikation lässt den Primärserver lokal committen und sendet WAL anschließend an die Replikate. Sie ist schneller für Schreibvorgänge, aber ein Primärserver-Absturz kann kürzliche Transaktionen verlieren, die noch kein Standby-Server erreicht haben.

Einrichtung der Streaming-Replikation (asynchrones Beispiel)

Die Einrichtung der Streaming-Replikation umfasst die Konfiguration sowohl des Primär- als auch des Replikat-Servers. Hier ist eine vereinfachte Anleitung:

1. Konfigurieren Sie den Primärserver (`postgresql.conf` und `pg_hba.conf`)

Auf dem Primärserver müssen Sie die WAL-Archivierung und Replikationsverbindungen aktivieren.

postgresql.conf-Änderungen:
```
wal_level = replica  # oder logical für logische Replikation
max_wal_senders = 5  # Anzahl gleichzeitiger Replikationsverbindungen
wal_keep_size = 512MB # Oder wal_keep_segments für ältere Versionen
# Für synchrone Replikation fügen Sie hinzu:
# synchronous_standby_names = 'replica1,replica2'
# Oder für spezifischen Servernamen/Priorität:
# synchronous_standby_names = '1 (replica1), 2 (replica2)'
archive_mode = on
archive_command = 'test ! -f /path/to/wal_archive/%f && cp %p /path/to/wal_archive/%f'
```
- wal_level: Muss mindestens replica für Streaming-Replikation sein.
- max_wal_senders: Gibt an, wie viele Standby-Server gleichzeitig verbinden können.
- wal_keep_size: Verhindert, dass WAL-Dateien gelöscht werden, bevor Replikate sie abrufen können (eine einfachere Alternative zu archive_command für grundlegende Setups, aber Archivierung wird für Robustheit empfohlen).
- archive_mode und archive_command: Nützlich für Point-in-Time-Recovery (PITR) und für Replikate, die alte WAL benötigen, nachdem sie zurückgefallen sind. Verwenden Sie in der Produktion ein echtes Archivziel oder ein Backup-Tool anstelle eines lokalen Kopierbefehls.

pg_hba.conf-Änderungen:

Erlauben Sie dem Replikat, sich für die Replikation zu verbinden. Ersetzen Sie replica_ip_address durch die tatsächliche IP Ihres Replikats.

# TYPE  DATABASE        USER            ADDRESS                 METHOD
host    replication     replication_user  replica_ip_address/32   md5

Sie müssen auch einen Replikationsbenutzer erstellen:

-- Auf dem Primärserver:
CREATE ROLE replication_user WITH REPLICATION LOGIN PASSWORD 'your_password';

Nachdem Sie diese Dateien geändert haben, laden Sie die PostgreSQL-Konfiguration neu:

pg_ctl reload
# Oder starten Sie PostgreSQL bei Bedarf neu

2. Bereiten Sie den Replikat-Server vor

Bevor Sie das Replikat starten, muss es ein Datenverzeichnis haben, das eine Kopie des Datenverzeichnisses des Primärservers zu einem bestimmten Zeitpunkt ist. Der einfachste Weg ist die Verwendung von pg_basebackup.

Stoppen Sie PostgreSQL auf dem Replikat (falls es läuft).
Erstellen Sie ein Basis-Backup:
```
# Stellen Sie sicher, dass PGDATA zuerst leer oder entfernt ist
pg_basebackup -h primary_host_ip -p 5432 -U replication_user -D /var/lib/postgresql/data/ -Fp -Xs -P -R
```
- -h, -p, -U: Geben Sie die Verbindungsdetails des Primärservers an.
- -D: Das Datenverzeichnis für das Replikat.
- -Fp: Format ist plain.
- -Xs: Streamen Sie WAL während des Backups.
- -P: Zeigen Sie den Fortschritt an.
- -R: Schreiben Sie Standby-Verbindungseinstellungen und erstellen Sie standby.signal für PostgreSQL 12 und neuer.
- Sie werden nach dem Passwort des replication_user gefragt.

3. Konfigurieren Sie den Replikat-Server

postgresql.conf-Änderungen (für PG12+):
```
hot_standby = on # Ermöglicht schreibgeschützte Abfragen auf dem Replikat
primary_conninfo = 'host=primary_host_ip port=5432 user=replication_user password=your_password'
```
- hot_standby: Aktiviert schreibgeschützte Abfragen auf dem Standby-Server.
- primary_conninfo: Verbindungszeichenfolge zum Primärserver.
Ältere PostgreSQL-Versionen:

PostgreSQL 12 hat recovery.conf entfernt. Wenn Sie einen älteren Server verwalten, erstellen Sie recovery.conf im Replikat-Datenverzeichnis:
```
standby_mode = 'on'
primary_conninfo = 'host=primary_host_ip port=5432 user=replication_user password=your_password'
# Wenn Sie die Archivwiederherstellung anstelle von Streaming verwenden, würden Sie restore_command angeben
# restore_command = 'cp /path/to/wal_archive/%f %p'
# recovery_target_timeline = 'latest'
```
Bei PostgreSQL 12 und neuer wird der Standby-Modus durch standby.signal gesteuert, und primary_conninfo lebt normalerweise in postgresql.auto.conf, wenn es von pg_basebackup -R erstellt wurde.

4. Starten Sie den Replikat-Server

Starten Sie den PostgreSQL-Dienst auf dem Replikat. Es wird eine Verbindung zum Primärserver herstellen, WAL-Datensätze empfangen und mit der Synchronisierung beginnen. Sie können die Protokolle zur Bestätigung überprüfen.

Tipp: Für eine robuste Hochverfügbarkeit sollten Sie Tools wie Patroni oder repmgr in Betracht ziehen, die Failover und Verwaltung automatisieren.

Logische Replikation

Logische Replikation ist eine flexiblere und granularere Form der Replikation, die in PostgreSQL 10 eingeführt wurde. Anstatt ganze Datenblöcke oder WAL-Datensätze zu replizieren, repliziert sie Datenänderungen basierend auf ihrer logischen Bedeutung (z. B. INSERT-, UPDATE-, DELETE-Anweisungen) auf Zeilenebene. Dies wird erreicht, indem die WAL-Datensätze in einen Strom logischer Änderungen decodiert werden.

Hauptmerkmale und Anwendungsfälle:

Selektive Replikation: Sie können auswählen, welche Tabellen repliziert werden sollen. Neuere PostgreSQL-Versionen unterstützen auch Spaltenlisten in Publikationen, aber überprüfen Sie Ihre Serverversion, bevor Sie sich auf diese Funktion verlassen.
Versionsübergreifende Replikation: Die logische Replikation kann Daten zwischen verschiedenen Hauptversionen von PostgreSQL replizieren.
Schema-Kontrolle: Die logische Replikation repliziert DDL nicht automatisch. Erstellen Sie übereinstimmende Tabellen und wenden Sie Schema-Migrationen auf dem Abonnenten an.
Datentransformation: Obwohl nicht integriert, bietet die logische Replikation eine Grundlage für komplexere ETL-Prozesse (Extract, Transform, Load).
Replikation von einem Primärserver zu einem Replikat, das kein vollständiger Klon ist: Die Zieldatenbank muss keine vollständige physische Kopie der Quelle sein.

Wie es funktioniert:

Publisher: Die Quelldatenbank (Primärserver), in der Datenänderungen auftreten. Sie benötigt wal_level = logical. Änderungen werden aus dem WAL in einen logischen Strom decodiert.
Publikation: Eine benannte Menge von Tabellen auf dem Publisher, deren Änderungen repliziert werden.
Subscriber: Die Zieldatenbank (Replikat), die die Änderungen empfängt.
Abonnement: Eine Verbindung auf dem Subscriber, die eine Verbindung zum Publisher herstellt und die Änderungen aus einer bestimmten Publikation anwendet.

Einrichtung der logischen Replikation

1. Konfigurieren Sie den Publisher (Primärserver)

postgresql.conf-Änderungen:

wal_level = logical
max_replication_slots = 10 # Für logische Replikationsslots
max_wal_senders = 10     # Sollte mindestens max_replication_slots sein

Erstellen Sie eine Publikation:

-- Auf der Publisher-Datenbank:
CREATE PUBLICATION my_publication FOR TABLE 
    table1, 
    table2 
    WITH (publish = 'insert,update,delete');

-- Oder für alle Tabellen:
-- CREATE PUBLICATION all_tables_pub FOR ALL TABLES;

Laden Sie die Konfiguration auf dem Publisher neu.

2. Konfigurieren Sie den Subscriber (Replikat-Server)

Stellen Sie sicher, dass die Zieltabellen existieren: Die Subscriber-Datenbank muss die Zieltabellen mit demselben Schema wie der Publisher haben. Sie können sie manuell erstellen oder pg_dump verwenden, um das Schema zu extrahieren.
Erstellen Sie ein Abonnement:
```
-- Auf der Subscriber-Datenbank:
CREATE SUBSCRIPTION my_subscription
    CONNECTION 'host=publisher_host_ip port=5432 user=replication_user password=your_password dbname=publisher_db'
    PUBLICATION my_publication;
```
Der replication_user benötigt entsprechende Berechtigungen auf dem Publisher.

PostgreSQL erstellt automatisch einen Replikationsslot auf dem Publisher und beginnt mit der Anwendung von Änderungen. Sie können den Abonnementstatus mit pg_stat_subscription auf dem Subscriber überwachen.

Tipp: Die logische Replikation verwendet die integrierte logische Decodierungsinfrastruktur von PostgreSQL. Für grundlegende Publikationen und Abonnements ist keine separate Erweiterung erforderlich.

Auswahl der richtigen Replikationsmethode

Streaming-Replikation: Ideal für hohe Verfügbarkeit und Notfallwiederherstellung, wenn Sie eine exakte, bytegenaue Kopie des Primärservers benötigen. Die Einrichtung für die vollständige Datenbankreplikation ist einfacher und bietet die beste Leseskalierbarkeit für schreibgeschützte Replikate.
Logische Replikation: Am besten geeignet für selektive Datenverteilung, Migrationen, versionsübergreifende Upgrades oder wenn Sie nur eine Teilmenge von Daten replizieren müssen. Sie ermöglicht komplexere Szenarien wie die Replikation in verschiedene Schemas oder die Durchführung von Datentransformationen.

Fazit

Verwenden Sie Streaming-Replikation, wenn Sie einen vollständigen Standby-Server für Failover, Notfallwiederherstellung oder schreibgeschützten Datenverkehr benötigen. Verwenden Sie logische Replikation, wenn Sie ausgewählte Tabellen, versionsübergreifende Migration oder kontrollierte Datenbewegung zwischen verschiedenen Datenbanken benötigen.

Bevor Sie einem der Setups vertrauen, führen Sie eine Failover-Übung durch, überprüfen Sie die Anwendungsverbindungshandhabung, überwachen Sie die Replikationsverzögerung und stellen Sie sicher, dass Backups immer noch sauber wiederhergestellt werden. Replikation hält einen anderen Server aktuell; sie ersetzt keine Betriebstests.