So konfigurieren Sie die PostgreSQL 12-Streaming-Replikation in CentOS 8

Die PostgreSQL-Datenbank unterstützt mehrere Replikationslösungen, um hochverfügbare, skalierbare und fehlertolerante Anwendungen zu erstellen, von denen eine der Write-Ahead Log (WAL)-Versand ist. Diese Lösung ermöglicht die Implementierung eines Standbyservers mithilfe von dateibasiertem Protokollversand oder Streamingreplikation oder, wenn möglich, mit einer Kombination aus beiden Ansätzen.

Bei der Streaming-Replikation wird ein Standby-Datenbankserver (Replikations-Slave) so konfiguriert, dass er eine Verbindung zum Master-/Primärserver herstellt, der WAL-Datensätze beim Generieren an den Standby-Server streamt, ohne darauf zu warten, dass die WAL-Datei gefüllt ist.

Standardmäßig ist die Streamingreplikation asynchron, d. h. die Daten werden auf die Standbyserver geschrieben, nachdem für eine Transaktion auf dem primären Server ein Commit ausgeführt wurde. Das bedeutet, dass es eine kleine Verzögerung zwischen dem Commit einer Transaktion auf dem Master-Server und den Änderungen gibt, die auf dem Standby-Server sichtbar werden. Ein Nachteil dieses Ansatzes besteht darin, dass im Falle eines Absturzes des Master-Servers nicht festgeschriebene Transaktionen möglicherweise nicht repliziert werden und dies zu Datenverlust führen kann.

In diesem Leitfaden erfahren Sie, wie Sie eine Postgresql 12-Master-Standby-Streaming-Replikation unter CentOS 8 einrichten. Wir werden "Replikationssteckplätze" für den Standby-Server als Lösung verwenden, um zu verhindern, dass der Master-Server alte WAL-Segmente recycelt, bevor der Standby-Server sie empfangen hat.

Beachten Sie, dass Replikationsslots im Vergleich zu anderen Methoden nur die Anzahl der Segmente beibehalten, von denen bekannt ist, dass sie benötigt werden.

Testumgebung:

Diese Anleitung geht davon aus, dass Sie als Root über SSH mit Ihren Master- und Standby-Datenbankservern verbunden sind (verwenden Sie bei Bedarf den Befehl Sudo, wenn Sie als normaler Benutzer mit Administratorrechten verbunden sind):

Postgresql master database server: 		10.20.20.9
Postgresql standby database server:		10.20.20.8

Auf beiden Datenbankservern muss Postgresql 12 installiert sein, andernfalls siehe: So installieren Sie PostgreSQL und pgAdmin in CentOS 8.

Hinweis: PostgreSQL 12 bringt wichtige Änderungen an der Implementierung und Konfiguration der Replikation, wie z.B. das Ersetzen von recovery.conf und die Konvertierung von recovery.conf-Parametern in normale PostgreSQL-Konfigurationsparameter, was die Konfiguration der Cluster-Replikation erheblich erleichtert.

Schritt 1: Konfigurieren des PostgreSQL-Masters/Primärdatenbankservers

1. Wechseln Sie auf dem Master-Server zum Postgres-Systemkonto und konfigurieren Sie die IP-Adresse(n), an denen der Master-Server auf Verbindungen von Clients lauscht.

In diesem Fall verwenden wir *, was alle bedeutet.

# su - postgres
psql -c "ALTER SYSTEM SET listen_addresses TO '*';"

Der Befehl ALTER SYSTEM SET SQL ist eine leistungsstarke Funktion, um die Konfigurationsparameter eines Servers direkt mit einer SQL-Abfrage zu ändern. Die Konfigurationen werden in der Datei postgresql.conf.auto gespeichert, die sich im Stammverzeichnis des Datenordners befindet (z. B. /var/lib/pgsql/12/data/), und werden zusätzlich zu den in postgresql.conf gespeicherten Konfigurationen gelesen. Die Konfigurationen in der ersten haben jedoch Vorrang vor denen in der späteren und anderen verwandten Dateien.

2. Erstellen Sie dann mit dem Programm createuser eine Replikationsrolle, die für Verbindungen vom Standby-Server zum Master-Server verwendet wird. Im folgenden Befehl fordert das Flag -P zur Eingabe eines Kennworts für die neue Rolle auf, und -e gibt die Befehle wieder, die createuser generiert und an den Datenbankserver sendet.

# su – postgres
createuser --replication -P -e replicator
exit

3. Geben Sie dann den folgenden Eintrag am Ende der Client-Authentifizierungskonfigurationsdatei /var/lib/pgsql/12/data/pg_hba.conf ein, wobei das Datenbankfeld auf Replikation eingestellt ist, wie im Screenshot gezeigt.

host    replication     replicator      10.20.20.8/24     md5

4. Starten Sie nun den Postgres12-Dienst mit dem folgenden systemctl-Befehl neu, um die Änderungen zu übernehmen.

# systemctl restart postgresql-12.service

5. Wenn Sie den firewalld-Dienst ausgeführt haben, müssen Sie als Nächstes den Postgresql-Dienst in der firewalld-Konfiguration hinzufügen, um Anfragen vom Standby-Server an den Master zuzulassen.

# firewall-cmd --add-service=postgresql --permanent
firewall-cmd --reload

Schritt 2: Erstellen eines Basis-Backups zum Bootstrapping des Standby-Servers

6. Als nächstes müssen Sie eine Basissicherung des Master-Servers vom Standby-Server erstellen. Dies hilft beim Bootstrapping des Standby-Servers. Sie müssen den Postgresql 12-Dienst auf dem Standby-Server stoppen, zum Postgres-Benutzerkonto wechseln, das Datenverzeichnis (/var/lib/pgsql/12/data/) sichern und dann alles darunter löschen, wie gezeigt, bevor Sie die Basissicherung durchführen.

# systemctl stop postgresql-12.service
su - postgres
cp -R /var/lib/pgsql/12/data /var/lib/pgsql/12/data_orig
rm -rf /var/lib/pgsql/12/data/*

7. Verwenden Sie dann das pg_basebackup-Tool, um das Basis-Backup mit dem richtigen Besitz (dem Benutzer des Datenbanksystems, d. h. Postgres, innerhalb des Postgres-Benutzerkontos) und den richtigen Berechtigungen zu erstellen.

Im folgenden Befehl wird die Option

-h – gibt den Host an, der der Master-Server ist.
-D – gibt das Datenverzeichnis an.
-U – gibt den Verbindungsbenutzer an.
-P – ermöglicht die Fortschrittsberichterstattung.
-v – aktiviert den ausführlichen Modus.
-R – ermöglicht die Erstellung einer Wiederherstellungskonfiguration: Erstellt eine Standby.Signal-Datei und hängt die Verbindungseinstellungen an postgresql.auto.conf im Datenverzeichnis an.
-X – wird verwendet, um die erforderlichen Write-Ahead-Protokolldateien (WAL-Dateien) in die Sicherung aufzunehmen. Der Wert stream bedeutet, dass die WAL gestreamt wird, während die Sicherung erstellt wird.
-C – ermöglicht die Erstellung eines Replikationsslots, der durch die Option -S benannt wird, bevor die Sicherung gestartet wird.
-S – gibt den Namen des Replikationsslots an.

$ pg_basebackup -h 10.20.20.9 -D /var/lib/pgsql/12/data -U replicator -P -v  -R -X stream -C -S pgstandby1
exit

8. Wenn der Sicherungsvorgang abgeschlossen ist, sollte das neue Datenverzeichnis auf dem Standby-Server wie im Screenshot aussehen. Eine standby.signal wird erstellt und die Verbindungseinstellungen werden an postgresql.auto.conf angehängt. Sie können den Inhalt mit dem Befehl ls auflisten.

# ls -l /var/lib/pgsql/12/data/

Ein Replikations-Slave wird im "Hot Standby"-Modus ausgeführt, wenn der Parameter hot_standby in postgresql.conf auf on (der Standardwert) gesetzt ist und eine Standby.signal-Datei im Datenverzeichnis vorhanden ist.

9. Zurück auf dem Master-Server sollten Sie nun den Replikationsslot mit dem Namen pgstandby1 sehen können, wenn Sie die Ansicht pg_replication_slots wie folgt öffnen.

# su - postgres
psql -c "SELECT * FROM pg_replication_slots;"
exit

10. Um die Verbindungseinstellungen anzuzeigen, die an die Datei postgresql.auto.conf angehängt sind, verwenden Sie den Befehl cat.

# cat /var/lib/pgsql/12/data/postgresql.auto.conf

11. Starten Sie nun den normalen Datenbankbetrieb auf dem Standby-Server, indem Sie den PostgreSQL-Dienst wie folgt starten.

# systemctl start postgresql-12

Schritt 3: Testen der PostgreSQL-Streamingreplikation

12. Sobald eine Verbindung zwischen dem Master und dem Standby-Server erfolgreich hergestellt wurde, sehen Sie auf dem Standby-Server einen WAL-Empfängerprozess mit dem Status Streaming, den Sie in der pg_stat_wal_receiver-Ansicht überprüfen können.

$ psql -c "\x" -c "SELECT * FROM pg_stat_wal_receiver;"

und einen entsprechenden WAL-Senderprozess auf dem Master-/Primärserver mit dem Status Streaming und dem sync_state async haben, können Sie dies pg_stat_replication pg_stat_replication Ansicht überprüfen.

$ psql -c "\x" -c "SELECT * FROM pg_stat_replication;"

Aus dem obigen Screenshot geht hervor, dass die Streamingreplikation asynchron ist. Im nächsten Abschnitt wird gezeigt, wie Sie optional die synchrone Replikation aktivieren können.

13. Testen Sie nun, ob die Replikation einwandfrei funktioniert, indem Sie eine Testdatenbank auf dem Master-Server erstellen und prüfen, ob sie auf dem Standby-Server vorhanden ist.
[master]postgres=# CREATE DATABASE tecmint;
[standby]postgres=# \l

Optional: Aktivieren der synchronen Replikation

14. Die synchrone Replikation bietet die Möglichkeit, gleichzeitig einen Commit für eine Transaktion in die primäre Datenbank und die Standbydatenbank/das Standby-Replikat auszuführen (oder Daten zu schreiben). Sie bestätigt erst, dass eine Transaktion erfolgreich ist, wenn alle Änderungen, die durch die Transaktion vorgenommen wurden, auf einen oder mehrere synchrone Standbyserver übertragen wurden.

Um die synchrone Replikation zu aktivieren, muss der synchronous_commit auch auf on gesetzt werden (dies ist der Standardwert, sodass keine Änderungen erforderlich sind), und Sie müssen auch den Parameter synchronous_standby_names auf einen nicht leeren Wert festlegen. In diesem Leitfaden werden wir es auf alle setzen.

$ psql -c "ALTER SYSTEM SET synchronous_standby_names TO  '*';"

15. Laden Sie dann den PostgreSQL 12-Dienst neu, um die neuen Änderungen zu übernehmen.

# systemctl reload postgresql-12.service

16. Wenn Sie nun den WAL-Senderprozess auf dem primären Server erneut abfragen, sollte er den Status Streaming und die sync_state Synchronisierung anzeigen.

$ psql -c "\x" -c "SELECT * FROM pg_stat_replication;"

Wir sind am Ende dieses Leitfadens angelangt. Wir haben gezeigt, wie Sie die PostgreSQL 12-Master-Standby-Datenbank-Streaming-Replikation in CentOS 8 einrichten. Wir haben auch behandelt, wie Sie die synchrone Replikation in einem PostgreSQL-Datenbankcluster aktivieren.