PostgreSQL Die Datenbank unterstützt mehrere Replikationslösungen zum Erstellen hochverfügbarer, skalierbarer und fehlertoleranter Anwendungen, darunter Write-Ahead Log (WAL ) Versand. Diese Lösung ermöglicht die Implementierung eines Standby-Servers mit dateibasiertem Protokollversand oder Streaming-Replikation oder, sofern möglich, 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 streamt Aufzeichnungen in den Standby-Modus, sobald sie generiert werden, ohne auf die WAL zu warten auszufüllende Datei.
Standardmäßig ist die Streaming-Replikation asynchron, wobei Daten auf den/die Standby-Server geschrieben werden, nachdem eine Transaktion auf dem primären Server festgeschrieben wurde. Dies bedeutet, dass es eine kleine Verzögerung zwischen dem Festschreiben einer Transaktion auf dem Master-Server und dem Sichtbarwerden der Änderungen auf dem Standby-Server gibt. Ein Nachteil dieses Ansatzes besteht darin, dass im Falle eines Absturzes des Master-Servers alle nicht festgeschriebenen Transaktionen möglicherweise nicht repliziert werden und dies zu Datenverlust führen kann.
Diese Anleitung zeigt, wie man Postgresql 12 einrichtet Master-Standby-Streaming-Replikation auf CentOS 8 . Wir werden „Replikationsslots verwenden ” für den Standby als Lösung, um zu vermeiden, dass der Master-Server alte WAL recycelt Segmente, bevor der Standby sie empfangen hat.
Beachten Sie, dass Replikationsslots im Vergleich zu anderen Methoden nur die Anzahl von Segmenten behalten, die bekanntermaßen benötigt werden.
Testumgebung:
In dieser Anleitung wird davon ausgegangen, dass Sie sich als Root über SSH mit Ihren Master- und Standby-Datenbankservern verbunden haben (verwenden Sie Sudo Befehl ggf., wenn Sie als normaler Benutzer mit Administratorrechten angemeldet sind):
Postgresql master database server: 10.20.20.9 Postgresql standby database server: 10.20.20.8
Beide Datenbankserver müssen Postgresql 12 haben installiert, andernfalls siehe:So installieren Sie PostgreSQL und pgAdmin in CentOS 8.
Hinweis :PostgreSQL 12 enthält größere Änderungen an der Replikationsimplementierung und -konfiguration, wie z. B. das Ersetzen von recovery.conf und die Konvertierung von recovery.conf -Parameter in normale PostgreSQL-Konfigurationsparameter umwandeln, was die Konfiguration der Cluster-Replikation erheblich erleichtert.
Schritt 1:Konfigurieren des PostgreSQL-Master-/Primärdatenbankservers
1. Wechseln Sie auf dem Master-Server zum Postgres-Systemkonto und konfigurieren Sie die IP-Adresse(n), die der Master-Server auf Verbindungen von Clients überwacht.
In diesem Fall verwenden wir * also alle.
# su - postgres $ psql -c "ALTER SYSTEM SET listen_addresses TO '*';"
Das ALTER SYSTEM SET Der SQL-Befehl ist eine leistungsstarke Funktion, um die Konfigurationsparameter eines Servers direkt mit einer SQL-Abfrage zu ändern. Die Konfigurationen werden in der postgresql.conf.auto gespeichert Datei, die sich im Stammverzeichnis des Datenordners befindet (z. B. /var/lib/pgsql/12/data/ ) und lesen Sie zusätzlich zu denen, die in postgresql.conf gespeichert sind . Aber Konfigurationen in der ersteren haben Vorrang vor denen in der späteren und anderen verwandten Dateien.
IP-Adressen auf PostgreSQL-Master konfigurieren
2. Erstellen Sie dann mithilfe von createuser eine Replikationsrolle, die für Verbindungen vom Standby-Server zum Master-Server verwendet wird Programm. Im folgenden Befehl wird das -P flag fragt nach einem Passwort für die neue Rolle und -e wiederholt die Befehle, die createuser generiert und an den Datenbankserver sendet.
# su – postgres $ createuser --replication -P -e replicator $ exit
Replikationsbenutzer auf Pgmaster erstellen
3. Geben Sie dann am Ende der /var/lib/pgsql/12/data/pg_hba.conf folgenden Eintrag ein Client-Authentifizierungs-Konfigurationsdatei, wobei das Datenbankfeld auf Replikation eingestellt ist, wie im Screenshot gezeigt.
host replication replicator 10.20.20.8/24 md5
Replikationsauthentifizierung konfigurieren
4. Starten Sie nun Postgres12 neu Dienst mit dem folgenden systemctl-Befehl, um die Änderungen zu übernehmen.
# systemctl restart postgresql-12.service
5. Als nächstes, wenn Sie die Firewalld haben Dienst ausgeführt wird, müssen Sie 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 einer Basissicherung zum Bootstrap des Standby-Servers
6. Als nächstes müssen Sie vom Standby-Server aus ein Basis-Backup des Master-Servers 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 sichern (/var/lib/pgsql/12/data/ ), löschen Sie dann alles darunter, wie gezeigt, bevor Sie die Basissicherung erstellen.
# 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 Werkzeug, um das Basis-Backup mit dem richtigen Besitz zu erstellen (der Benutzer des Datenbanksystems, z. B. Postgres , innerhalb von Postgres Benutzerkonto) und mit den richtigen Berechtigungen.
Im folgenden Befehl ist 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 Fortschrittsberichte.-v– aktiviert den ausführlichen Modus.-R– ermöglicht die Erstellung einer Wiederherstellungskonfiguration:Erstellt ein standby.signal Datei und hängen Sie die Verbindungseinstellungen an postgresql.auto.conf an unter dem Datenverzeichnis.-X– Wird verwendet, um die erforderlichen Write-Ahead-Protokolldateien (WAL-Dateien) in die Sicherung aufzunehmen. Ein Wert von stream bedeutet, dass die WAL gestreamt wird, während die Sicherung erstellt wird.-C– ermöglicht die Erstellung eines Replikations-Slots, der durch die Option -S benannt wird, bevor die Sicherung gestartet wird.-S– gibt den Namen des Replikations-Slots an.
$ pg_basebackup -h 10.20.20.5 -D /var/lib/pgsql/12/data -U replicator -P -v -R -X stream -C -S pgstandby1 $ exit
Basis-Backup des Master-Servers
8. Wenn der Sicherungsvorgang abgeschlossen ist, sollte das neue Datenverzeichnis auf dem Standby-Server wie im Screenshot aussehen. Ein Standby.Signal erstellt und die Verbindungseinstellungen an postgresql.auto.conf angehängt . Sie können seinen Inhalt mit dem Befehl ls auflisten.
# ls -l /var/lib/pgsql/12/data/
Überprüfen Sie das Sicherungsdatenverzeichnis
Ein Replikations-Slave wird im „Hot Standby“ ausgeführt ”-Modus, wenn der hot_standby Parameter in postgresql.conf auf on (Standardwert) gesetzt ist und es gibt ein standby.signal Datei im Datenverzeichnis vorhanden.
9. Zurück auf dem Master-Server sollten Sie den Replikations-Slot mit dem Namen pgstandby1 sehen können wenn Sie die pg_replication_slots öffnen wie folgt anzeigen.
# su - postgres $ psql -c "SELECT * FROM pg_replication_slots;" $ exit
Replikationsslot erstellen
10. Zum Anzeigen der in postgresql.auto.conf angehängten Verbindungseinstellungen verwenden Sie den cat-Befehl.
# cat /var/lib/pgsql/12/data/postgresql.auto.conf
Verbindungseinstellungen anzeigen
11. Beginnen Sie nun den normalen Datenbankbetrieb auf dem Standby-Server, indem Sie den PostgreSQL-Dienst wie folgt starten.
# systemctl start postgresql-12
Schritt 3:PostgreSQL-Streaming-Replikation testen
12. Sobald eine Verbindung zwischen dem Master und dem Standby erfolgreich hergestellt wurde, sehen Sie ein WAL Receiver-Prozess im Standby-Server mit einem Streaming-Status, können Sie dies mit pg_stat_wal_receiver überprüfen ansehen.
$ psql -c "\x" -c "SELECT * FROM pg_stat_wal_receiver;"
Überprüfen Sie den WAL-Empfängerprozess
und eine entsprechende WAL Senderprozess im Master-/Primärserver mit einem Streaming-Status und einem sync_state von async können Sie diese Ansicht pg_stat_replication pg_stat_replication überprüfen.
$ psql -c "\x" -c "SELECT * FROM pg_stat_replication;"
Überprüfen Sie den WAL-Absenderprozess im Master
Aus dem obigen Screenshot geht hervor, dass die Streaming-Replikation asynchron ist. Im nächsten Abschnitt zeigen wir Ihnen, wie Sie optional die synchrone Replikation aktivieren.
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
Testen Sie die Streaming-Replikation
Optional:Synchrone Replikation aktivieren
14. Die synchrone Replikation bietet die Möglichkeit, eine Transaktion (oder Daten) gleichzeitig in die primäre Datenbank und die Standby-/Replik zu schreiben. Es bestätigt nur, dass eine Transaktion erfolgreich war, wenn alle von der Transaktion vorgenommenen Änderungen an einen oder mehrere synchrone Standby-Server übertragen wurden.
Um die synchrone Replikation zu aktivieren, muss das synchronous_commit muss ebenfalls auf on gesetzt sein (was der Standardwert ist, daher keine Änderung erforderlich) und Sie müssen auch die synchronous_standby_names setzen Parameter auf einen nicht leeren Wert. Für diese Anleitung setzen wir es auf all.
$ psql -c "ALTER SYSTEM SET synchronous_standby_names TO '*';"
Legen Sie Sync-Standby-Namen im Master fest
15. Laden Sie dann den PostgreSQL 12-Dienst neu, um die neuen Änderungen zu übernehmen.
# systemctl reload postgresql-12.service
16. Wenn Sie jetzt die WAL abfragen Absender-Prozess auf dem primären Server erneut senden, sollte er einen Streaming-Status und einen sync_state anzeigen von sync .
$ psql -c "\x" -c "SELECT * FROM pg_stat_replication;"
Überprüfen Sie den WAL-Absenderprozess im Master
Wir sind am Ende dieses Leitfadens angelangt. Wir haben gezeigt, wie Sie PostgreSQL 12 einrichten Master-Standby-Datenbank-Streaming-Replikation in CentOS 8 . Wir haben auch behandelt, wie man die synchrone Replikation in einem PostgreSQL-Datenbank-Cluster aktiviert.
Es gibt viele Verwendungsmöglichkeiten für die Replikation und Sie können immer eine Lösung auswählen, die Ihrer IT-Umgebung und/oder anwendungsspezifischen Anforderungen entspricht. Weitere Einzelheiten finden Sie unter Log-Shipping Standby Servers in der PostgreSQL 12-Dokumentation.
Sharing is Caring…Auf Facebook teilenAuf Twitter teilenAuf Linkedin teilenAuf Reddit teilen