PostgreSQL
 sql >> Datenbank >  >> RDS >> PostgreSQL

Erste Schritte mit der PostgreSQL-Streaming-Replikation

In diesem Blogpost befassen wir uns mit den Grundlagen der Einrichtung von Streaming Replication (SR) in PostgreSQL. Die Streaming-Replikation ist der grundlegende Baustein zum Erreichen einer hohen Verfügbarkeit in Ihrem PostgreSQL-Hosting und wird durch Ausführen einer Master-Slave-Konfiguration erzeugt.

Master-Slave-Terminologie

Master-/Primärserver

  • Der Server, der Schreibvorgänge annehmen kann.
  • Auch Lese-/Schreibserver genannt.

Slave-/Standby-Server

  • Ein Server, auf dem die Daten ständig mit dem Master synchronisiert werden.
  • Auch Sicherungsserver oder Replikat genannt.
  • Ein Warm-Standby-Server ist ein Server, mit dem keine Verbindung hergestellt werden kann, bis er zum Master-Server hochgestuft wurde.
  • Im Gegensatz dazu kann ein Hot-Standby-Server Verbindungen annehmen und schreibgeschützte Abfragen verarbeiten. Für den Rest dieser Diskussion werden wir uns nur auf Hot-Standby-Server konzentrieren.

Daten werden auf den Master-Server geschrieben und an die Slave-Server weitergegeben. Falls es ein Problem mit dem vorhandenen Master-Server gibt, übernimmt einer der Slave-Server und übernimmt weiterhin Schreibvorgänge, um die Verfügbarkeit des Systems sicherzustellen.

Versandbasierte WAL-Replikation

Was ist WAL?

  • WAL steht für Write-Ahead Logging.
  • Es ist eine Protokolldatei, in die alle Änderungen an der Datenbank geschrieben werden, bevor sie auf Datendateien angewendet/geschrieben werden.
  • WAL wird zur Wiederherstellung nach einem Datenbankabsturz verwendet, um die Datenintegrität sicherzustellen.
  • WAL wird in Datenbanksystemen verwendet, um Atomarität und Dauerhaftigkeit zu erreichen.

Wie wird WAL für die Replikation verwendet?

Write-Ahead-Protokolldatensätze werden verwendet, um die Daten zwischen den Datenbankservern synchron zu halten. Dies wird auf zwei Arten erreicht:

Dateibasierter Protokollversand

  • WAL-Protokolldateien werden vom Master an die Standby-Server gesendet, um die Daten synchron zu halten.
  • Der Master kann die Protokolle direkt in den Speicher des Standby-Servers kopieren oder den Speicher mit den Standby-Servern teilen.
  • Eine WAL-Protokolldatei kann bis zu 16 MB an Daten enthalten.
  • Die WAL-Datei wird erst versendet, nachdem sie diesen Schwellenwert erreicht hat.
  • Dies führt zu einer Verzögerung bei der Replikation und erhöht auch die Wahrscheinlichkeit, dass Daten verloren gehen, wenn der Master abstürzt und Protokolle nicht archiviert werden

WAL-Datensätze streamen

  • WAL-Record-Blöcke werden von Datenbankservern gestreamt, um die Daten synchron zu halten.
  • Der Standby-Server verbindet sich mit dem Master, um die WAL-Chunks zu empfangen.
  • Die WAL-Einträge werden gestreamt, während sie generiert werden.
  • Das Streaming von WAL-Einträgen muss nicht warten, bis die WAL-Datei gefüllt ist.
  • Dies ermöglicht einem Standby-Server, aktueller zu bleiben, als dies mit dateibasiertem Protokollversand möglich ist.
  • Standardmäßig ist die Streaming-Replikation asynchron, obwohl sie auch die synchrone Replikation unterstützt.

Beide Methoden haben ihre Vor- und Nachteile. Die Verwendung des dateibasierten Versands ermöglicht eine Point-in-Time-Wiederherstellung und kontinuierliche Archivierung, während das Streaming die sofortige Datenverfügbarkeit auf den Standby-Servern gewährleistet. Sie können PostgreSQL jedoch so konfigurieren, dass beide Methoden gleichzeitig verwendet werden, und die Vorteile nutzen. In diesem Blog konzentrieren wir uns hauptsächlich auf die Streaming-Replikation, um eine hohe Verfügbarkeit von PostgreSQL zu erreichen.

So richten Sie die Streaming-Replikation in PostgreSQL für Hochverfügbarkeit einClick To Tweet

Wie richte ich die Streaming-Replikation ein?

Das Einrichten der Streaming-Replikation in PostgreSQL ist sehr einfach. Angenommen, PostgreSQL ist bereits auf allen Servern installiert, können Sie diesen Schritten folgen, um loszulegen:

Konfiguration auf Master-Knoten

  • Initialisieren Sie die Datenbank auf dem Master-Knoten mit dem Dienstprogramm initdb.
  • Erstellen Sie eine Rolle/einen Benutzer mit Replikationsberechtigungen, indem Sie den folgenden Befehl ausführen. Nachdem Sie den Befehl ausgeführt haben, können Sie ihn überprüfen, indem Sie \du ausführen, um sie auf psql.
      aufzulisten
    •   CREATE USER REPLICATION LOGIN ENCRYPTED PASSWORD ’’;
  • Konfigurieren Sie Eigenschaften im Zusammenhang mit der Streaming-Replikation in der PostgreSQL-Master-Konfigurationsdatei (postgresql.conf):
    # Mögliche Werte sind replica|minimal|logical
    wal_level =Replikatnummer erforderlich für pg_rewind-Fähigkeit, wenn Standby nicht mehr mit master
    wal_log_hints synchronisiert ist =on# legt die maximale Anzahl gleichzeitiger Verbindungen von den Standby-Servern fest.
    max_wal_senders =3
    # Der folgende Parameter wird verwendet, um dem Master mitzuteilen, dass er die Mindestanzahl von
    # Segmenten von WAL-Protokollen aufbewahren soll, damit sie nicht gelöscht werden, bevor Standby sie verbraucht.
    # jedes Segment ist 16 MB
    wal_keep_segments =8
    # Der folgende Parameter aktiviert eine Nur-Lese-Verbindung auf dem Knoten, wenn er sich in der
    # Standby-Rolle befindet. Dies wird ignoriert, wenn der Server als Master läuft.
    hot_standby =ein
  • Fügen Sie einen Replikationseintrag in der Datei pg_hba.conf hinzu, um Replikationsverbindungen zwischen den Servern zuzulassen:
    # Replikationsverbindungen von localhost zulassen,
    # durch einen Benutzer mit dem Replikationsrecht.
    # TYPE    DATABASE    USER    ADDRESS    METHOD
    host    replication    repl_user    IPaddress(CIDR)    md5
  • Starten Sie den PostgreSQL-Dienst auf dem Master-Knoten neu, damit die Änderungen wirksam werden.

Konfiguration auf Standby-Knoten

  • Erstellen Sie das Basis-Backup des Master-Knotens mit dem Dienstprogramm pg_basebackup und verwenden Sie es als Ausgangspunkt für den Standby-Modus.
    # Erläuterung einiger Optionen, die für das Dienstprogramm pg_basebackup verwendet werden# -X wird verwendet, um die erforderlichen Transaktionsprotokolldateien (WAL-Dateien) in die Sicherung
    # aufzunehmen. Wenn Sie stream angeben, öffnet dies eine zweite Verbindung zum Server
    # und startet das Streamen des Transaktionsprotokolls gleichzeitig mit der Ausführung der Sicherung.
    # -c ist die Checkpoint-Option. Die Einstellung auf schnell erzwingt, dass der Prüfpunkt
    # bald erstellt wird.
    # -W zwingt pg_basebackup zur Eingabe eines Passworts, bevor eine Verbindung
    # mit einer Datenbank hergestellt wird.
    pg_basebackup -D  -h -X stream -c fast -U repl_user -W
  • Erstellen Sie die Replikationskonfigurationsdatei, falls nicht vorhanden (sie wird automatisch erstellt, wenn die Option -R in pg_basebackup bereitgestellt wird):
    # Gibt an, ob der Server gestartet werden soll eine Bereitschaft. Bei der Streaming-Replikation
    # muss dieser Parameter auf on gesetzt werden.
    standby_mode =‘on’# Gibt eine Verbindungszeichenfolge an, die für den Standby-Server verwendet wird, um sich
    # mit dem Primary/Master.
    primary_conninfo zu verbinden =‘host= port= user= password= application_name=”host_name”’# Gibt die Wiederherstellung zu einer bestimmten Zeitachse an. Die Standardeinstellung ist die Wiederherstellung entlang der
    # gleichen Zeitleiste, die aktuell war, als die Basissicherung erstellt wurde.
    # Wenn Sie dies auf „Neueste“ setzen, wird die letzte Zeitleiste wiederhergestellt, die
    # im Archiv gefunden wurde nützlich auf einem Standby-Server.
    recovery_target_timeline =„neueste“
  • Standby starten.

Die Standby-Konfiguration muss auf allen Standby-Servern durchgeführt werden. Sobald die Konfiguration abgeschlossen ist und ein Standby gestartet wurde, stellt es eine Verbindung zum Master her und startet das Streamen von Protokollen. Dadurch wird die Replikation eingerichtet und kann durch Ausführen der SQL-Anweisung „SELECT * FROM pg_stat_replication; überprüft werden “.

Standardmäßig ist die Streaming-Replikation asynchron. Wenn Sie es synchron machen möchten, können Sie es mit den folgenden Parametern konfigurieren:

# num_sync ist die Anzahl der synchronen Standbys, von denen Transaktionen
# auf Antworten warten müssen.
# standby_name ist derselbe wie der Wert application_name in recovery.conf
# Wenn alle Standby-Server für synchron berücksichtigt werden müssen, dann setze den Wert '*'
# Wenn nur bestimmte Standby-Server berücksichtigt werden müssen, dann gib sie als
# kommaseparierte Liste von standby_name an .
# Der Name eines Standby-Servers für diesen Zweck ist die application_name-Einstellung des
# Standby-Servers, wie in der primary_conninfo des
# Standby-WAL-Empfängers festgelegt.
synchronous_standby_names =‘num_sync ( standby_name [, ...] )’

Synchronous_commit muss für die synchrone Replikation aktiviert sein, und dies ist die Standardeinstellung. PostgreSQL bietet sehr flexible Optionen für synchrones Commit und kann auf Benutzer-/Datenbankebene konfiguriert werden. Gültige Werte sind wie folgt:

  • Aus – Die Transaktion wird dem Client bestätigt, noch bevor dieser Transaktionsdatensatz tatsächlich in die WAL-Protokolldatei auf diesem Knoten übertragen wird.
  • Lokal –  Die Transaktionsfestschreibung wird dem Client erst bestätigt, nachdem dieser Transaktionsdatensatz in die WAL-Protokolldatei auf diesem Knoten geleert wurde.
  • Remote_write – Der Transaktionscommit wird dem Client erst bestätigt, nachdem der/die Server, der/die durch synchron_standby_names angegeben ist/sind, bestätigt hat/haben, dass der Transaktionsdatensatz in den Disk-Cache geschrieben wurde, aber nicht notwendigerweise nachdem er in die WAL-Protokolldatei geleert wurde.
  • Ein – Der Transaktionscommit wird dem Client erst bestätigt, nachdem der/die durch Synchronous_standby_names angegebene/n Server bestätigt hat/haben, dass der Transaktionsdatensatz in die WAL-Protokolldatei geschrieben wurde.
  • Remote_apply – Der Transaktionscommit wird dem Client erst bestätigt, nachdem der/die Server, der/die durch synchron_standby_names angegeben ist/sind, bestätigt haben, dass der Transaktionsdatensatz in die WAL-Protokolldatei geleert und auf die Datenbank angewendet wurde.

Synchronous_commit im synchronen Replikationsmodus auf „off“ oder „local“ zu setzen, funktioniert wie asynchron und kann Ihnen dabei helfen, eine bessere Schreibleistung zu erzielen. Dies birgt jedoch ein höheres Risiko von Datenverlusten und Leseverzögerungen auf Standby-Servern. Wenn es auf remote_apply gesetzt ist, stellt es die sofortige Datenverfügbarkeit auf Standby-Servern sicher, aber die Schreibleistung kann sich verschlechtern, da es auf alle/erwähnten Standby-Server angewendet werden sollte.

Sie können den Archivmodus aktivieren, wenn Sie beabsichtigen, kontinuierliche Archivierung und Point-in-Time-Wiederherstellung zu verwenden. Obwohl dies für die Streaming-Replikation nicht obligatorisch ist, hat die Aktivierung des Archivmodus zusätzliche Vorteile. Wenn der Archivmodus nicht aktiviert ist, müssen wir die Replikationsslots verwenden Funktion oder stellen Sie sicher, dass wal_keep_segments Der Wert ist basierend auf der Last hoch genug eingestellt.

Weitere Einzelheiten zur Hochverfügbarkeit in PostgreSQL finden Sie in dieser ausgezeichneten Präsentation. In unserem nächsten Blog-Beitrag stellen wir Ihnen die Welt der Tools vor, mit denen die Hochverfügbarkeit für PostgreSQL mithilfe von Streaming-Replikation verwaltet wird.