DevOps Wissensdatenbank
DevOps Wissensdatenbank

PostgreSQL-Replikation meistern: Typen und Einrichtung erklärt

Meistern Sie die PostgreSQL-Replikation mit diesem umfassenden Leitfaden. Erfahren Sie mehr über Streaming- (physische) und logische Replikation, deren Anwendungsfälle und wie Sie diese konfigurieren. Sorgen Sie für Hochverfügbarkeit, Notfallwiederherstellung und Leseskalierbarkeit für Ihre fortschrittliche Open-Source-Relationale Datenbank.

42 Aufrufe

PostgreSQL-Replikation meistern: Typen und Einrichtung erklärt

In der Welt der fortschrittlichen Open-Source-Relationalen Datenbanken sticht PostgreSQL durch seine Robustheit, Erweiterbarkeit und leistungsstarken Funktionen hervor. Unter diesen sind Datenredundanz und Hochverfügbarkeit für geschäftskritische Anwendungen von größter Bedeutung. Die PostgreSQL-Replikation ist der Mechanismus, mit dem Sie diese Ziele erreichen können, indem Daten von einem PostgreSQL-Server (dem Primärserver) auf einen oder mehrere andere PostgreSQL-Server (die Replikate oder Standbys) kopiert werden.

Dieser Artikel befasst sich mit den Kernkonzepten der PostgreSQL-Replikation, untersucht die verschiedenen verfügbaren Typen und bietet praktische Anleitungen zur Einrichtung. Das Verständnis dieser Mechanismen ist entscheidend, um sicherzustellen, dass Ihre Daten immer zugänglich, vor Hardwarefehlern geschützt und in der Lage sind, erhöhte Leselast zu bewältigen. Wir werden sowohl Streaming-Replikation als auch logische Replikation behandeln und ihre Anwendungsfälle, Vorteile und Konfigurationsschritte erläutern.

Warum PostgreSQL-Replikation wichtig ist

Bevor wir uns dem „Wie“ widmen, ist es wichtig, das „Warum“ zu verstehen. Datenverlust oder längere Ausfallzeiten können schwerwiegende Folgen für Unternehmen haben. Die Replikation adressiert diese Bedenken durch:

  • Hochverfügbarkeit (HA): Wenn der Primärserver ausfällt, kann ein Replikat schnell zum neuen Primärserver befördert werden, wodurch Ausfallzeiten minimiert werden.
  • Disaster Recovery (DR): Replikate können an verschiedenen geografischen Standorten platziert werden, um Ihre Daten vor standortspezifischen Katastrophen zu schützen.
  • Lese-Skalierbarkeit: Das Auslagern leseintensiver Workloads auf Replikate kann die Leistung des Primärservers verbessern, der weiterhin Schreibvorgängen gewidmet ist.
  • Datenschutz: Die Replikation fungiert als kontinuierliches Backup und bietet eine aktuellere Kopie Ihrer Daten als herkömmliche periodische Backups.

PostgreSQL bietet zwei Hauptmethoden für die Replikation: Streaming-Replikation und logische Replikation. Obwohl beide Datensynchronisation erreichen, operieren sie nach unterschiedlichen Prinzipien und eignen sich für unterschiedliche Szenarien.

Streaming-Replikation (Physische Replikation)

Die Streaming-Replikation ist die gebräuchlichste und grundlegendste Form der Replikation in PostgreSQL. Sie funktioniert, indem Write-Ahead-Log (WAL)-Datensätze vom Primärserver an ein oder mehrere Replikate gesendet werden. Diese WAL-Datensätze stellen jede Änderung dar, die an der Datenbank vorgenommen wurde. 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.

Arten der Streaming-Replikation:

  1. Synchrone Replikation: Im synchronen Modus wartet der Primärserver auf die Bestätigung von mindestens einem (oder einer angegebenen Anzahl) von Replikaten, dass die WAL-Datensätze empfangen und in ihren WAL-Puffer geschrieben wurden, bevor er dem Client die Bestätigung des Transaktionscommits mitteilt. Dies garantiert, dass bestätigte Transaktionen auf mindestens einem Replikat vorhanden sind, was das höchste Maß an Datenkonsistenz bietet.

    • Vorteile: Garantiert keinen Datenverlust für bestätigte Transaktionen auf dem synchronen Replikat.
    • Nachteile: Kann zu Latenzen bei Transaktionscommits führen, da der Primärserver auf die Bestätigung des Replikats warten muss.

  2. Asynchrone Replikation: Im asynchronen Modus sendet der Primärserver WAL-Datensätze an die Replikate, wartet aber nicht auf eine Bestätigung, bevor die Transaktion bestätigt wird. Der Primärserver bestätigt den Commit sofort nach dem lokalen Schreiben des WAL an den Client. Dies bietet eine geringere Latenz, birgt aber das Risiko von Datenverlust, wenn der Primärserver ausfällt, bevor die WAL-Datensätze an das Replikat gesendet und angewendet wurden.

    • Vorteile: Minimale Auswirkung auf die Latenz von Transaktionscommits.
    • Nachteile: Möglicher Datenverlust, wenn der Primärserver ausfällt und die WAL-Datensätze das Replikat noch nicht erreicht haben.

Streaming-Replikation einrichten (Beispiel für asynchrone Replikation)

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

1. Primärserver konfigurieren (postgresql.conf und pg_hba.conf)

Auf dem Primärserver müssen Sie das WAL-Archivieren und Replikationsverbindungen aktivieren.

  • Änderungen an postgresql.conf:

    ```ini
    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 hinzufügen:

    synchronous_standby_names = 'replica1,replica2'

    Oder für spezifischen Servernamen/Priorität:

    synchronous_standby_names = '1 (replica1), 2 (replica2)'

    archive_mode = on
    archive_command = 'cp %p /path/to/wal_archive/%f'
    `` *wal_level: Muss mindestensreplicafür Streaming-Replikation sein. *max_wal_senders: Gibt an, wie viele Standby-Server gleichzeitig verbunden werden können. *wal_keep_size: Verhindert, dass WAL-Dateien gelöscht werden, bevor Replikate sie abrufen können (eine einfachere Alternative zuarchive_commandfür einfache Setups, aber Archivierung wird für Robustheit empfohlen). *archive_mode&archive_command`: Entscheidend für Point-in-Time Recovery (PITR) und unerlässlich, wenn ein Replikat zu weit zurückfällt oder neu aufgebaut werden muss.

  • Änderungen an pg_hba.conf:

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

    ```ini

    TYPE DATABASE USER ADDRESS METHOD

    host replication replication_user replica_ip_address/32 md5
    ```

    Sie müssen auch einen Replikationsbenutzer erstellen:

    sql -- 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:

    ```bash
    pg_ctl reload

    Oder starten Sie PostgreSQL neu, falls erforderlich

    ```

2. Replikatserver vorbereiten

Bevor das Replikat gestartet wird, 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.

  • PostgreSQL auf dem Replikat stoppen (falls ausgeführt).

  • Basis-Backup erstellen:

    ```bash

    Stellen Sie sicher, dass PGDATA leer ist oder zuerst entfernt wurde

    pg_basebackup -h primary_host_ip -p 5432 -U replication_user -D /var/lib/postgresql/data/ -Fp -Xs -P
    `` *-h,-p,-U: Geben Sie die Verbindungsinformationen des Primärservers an. *-D: Das Datenverzeichnis für das Replikat. *-Fp: Das Format ist Plain. *-Xs: Verwendet Stream TSL/WAL-Streaming. Entspricht der Einstellungprimary_conninfofür WAL-Streaming. *-P: Zeigt den Fortschritt an. * Sie werden nach dem Passwort fürreplication_user` gefragt.

3. Replikatserver konfigurieren (postgresql.conf und recovery.conf oder postgresql.conf für PG12+)

  • Änderungen an postgresql.conf (für PG12+):

    ```ini
    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'

    Für synchrone Replikation hinzufügen:

    primary_promote_delay = 10 # Sekunden

    Oder verwenden Sie einen Trigger-Datei-Mechanismus

    `` *hot_standby: Ermöglicht schreibgeschützte Abfragen auf dem Standby. *primary_conninfo`: Verbindungszeichenfolge zum Primärserver.

  • recovery.conf (für PostgreSQL-Versionen vor 12):

    Erstellen Sie eine Datei recovery.conf im Datenverzeichnis des Replikats mit folgendem Inhalt:

    ```ini
    standby_mode = 'on'
    primary_conninfo = 'host=primary_host_ip port=5432 user=replication_user password=your_password'

    Wenn Sie stattdessen Archivwiederherstellung anstelle von Streaming verwenden, würden Sie restore_command angeben

    restore_command = 'cp /path/to/wal_archive/%f %p'

    recovery_target_timeline = 'latest'

    ```

    Für PG12+ werden primary_conninfo und hot_standby direkt in postgresql.conf gesetzt.

4. Replikatserver starten

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

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

Logische Replikation

Die 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 geschieht durch Dekodieren der WAL-Datensätze in einen Strom logischer Änderungen.

Hauptmerkmale und Anwendungsfälle:

  • Selektive Replikation: Sie können auswählen, welche Tabellen oder sogar welche Spalten repliziert werden sollen. Dies ist sehr vorteilhaft für die selektive Übertragung von Daten zwischen Datenbanken.
  • Versionenübergreifende Replikation: Logische Replikation kann Daten zwischen verschiedenen Hauptversionen von PostgreSQL replizieren.
  • Selektive Schemaänderungen: Sie können Änderungen für bestimmte Datenbanken oder Schemata replizieren und nur bestimmte Tabellen veröffentlichen.
  • Datentransformation: Obwohl nicht integriert, bietet die logische Replikation eine Grundlage für komplexere ETL-Prozesse (Extract, Transform, Load).
  • Replikation von einem Primärserver auf ein Replikat, das kein vollständiger Klon ist: Die Zieldatenbank muss keine vollständige physische Kopie der Quelle sein.

Funktionsweise:

  1. Herausgeber (Publisher): Die Quelldatenbank (Primärserver), in der Datenänderungen stattfinden. Sie benötigt wal_level = logical. Änderungen werden aus WAL in einen logischen Strom dekodiert.
  2. Veröffentlichung (Publication): Eine benannte Menge von Tabellen auf dem Herausgeber, deren Änderungen repliziert werden sollen.
  3. Abonnent (Subscriber): Die Zieldatenbank (Replikat), die die Änderungen empfängt.
  4. Abonnement (Subscription): Eine Verbindung auf dem Abonnenten, die sich mit dem Herausgeber verbindet und die Änderungen aus einer bestimmten Veröffentlichung anwendet.

Logische Replikation einrichten

1. Herausgeber (Primärserver) konfigurieren

  • Änderungen an postgresql.conf:

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

  • Veröffentlichung erstellen:

    ```sql
    -- In der Herausgeberdatenbank:
    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 Herausgeber neu.

2. Abonnent (Replikatserver) konfigurieren

  • Stellen Sie sicher, dass die Zieltabelle existieren: Die Abonnentendatenbank muss die Zieltabelle mit demselben Schema wie der Herausgeber haben. Sie können sie manuell erstellen oder pg_dump verwenden, um das Schema zu extrahieren.

  • Abonnement erstellen:

    sql -- In der Abonnentendatenbank: 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 die entsprechenden Berechtigungen auf dem Herausgeber.

    PostgreSQL erstellt automatisch einen Replikationsslot auf dem Herausgeber und beginnt mit dem Anwenden der Änderungen. Sie können den Status des Abonnements mit pg_stat_subscription auf dem Abonnenten überwachen.

Tipp: Logische Replikation erfordert die Erweiterung logical decoding, die normalerweise integriert ist. Sie ist ressourcenintensiver als Streaming-Replikation, bietet aber mehr Flexibilität.

Die richtige Replikationsmethode wählen

  • Streaming-Replikation: Ideal für Hochverfügbarkeit und Disaster Recovery, wenn Sie eine exakte, Byte-für-Byte-Kopie des Primärservers benötigen. Sie ist einfacher einzurichten für die Replikation der gesamten Datenbank und bietet die beste Lese-Skalierbarkeit für schreibgeschützte Replikate.
  • Logische Replikation: Am besten geeignet für selektive Datenverteilung, Migrationen, versionsübergreifende Upgrades oder wenn Sie nur einen Teil der Daten replizieren müssen. Sie ermöglicht komplexere Szenarien wie die Replikation auf verschiedene Schemata oder die Durchführung von Datentransformationen.

Fazit

Die PostgreSQL-Replikation ist eine leistungsstarke Funktion, die robuste Datenverfügbarkeit, Wiederherstellung und Skalierbarkeit ermöglicht. Ob Sie sich für die umfassende Datenspiegelung der Streaming-Replikation oder den flexiblen, selektiven Ansatz der logischen Replikation entscheiden, das Verständnis ihrer Mechanismen und Konfigurationen ist der Schlüssel zur Aufrechterhaltung einer gesunden und widerstandsfähigen PostgreSQL-Umgebung. Durch die Implementierung der Replikation verbessern Sie die Fehlertoleranz und die Leistungsfähigkeit Ihrer Datenbank erheblich.

Testen Sie Ihr Replikationssetup immer gründlich, insbesondere Failover-Szenarien, und überwachen Sie die Replikationsverzögerung, um sicherzustellen, dass Ihre Replikate auf dem neuesten Stand sind. Kontinuierliches Lernen und Anpassung an die sich entwickelnden Funktionen von PostgreSQL werden Ihre Beherrschung dieses unverzichtbaren Datenbanksystems weiter festigen.