Website-Suche

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

Die PostgreSQL-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, wenn möglich, einer Kombination beider Ansätze.

Bei der Streaming-Replikation wird ein Standby-Datenbankserver (Replikationsslave) so konfiguriert, dass er eine Verbindung zum Master-/Primärserver herstellt, der WAL-Datensätze an den Standby-Server streamt, sobald sie generiert werden, ohne auf die WAL-Daten warten zu müssen Datei, die gefüllt werden soll.

Standardmäßig ist die Streaming-Replikation asynchron, wobei Daten auf den/die Standby-Server geschrieben werden, nachdem eine Transaktion auf dem Primärserver 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 bei einem Absturz des Master-Servers nicht festgeschriebene Transaktionen möglicherweise nicht repliziert werden, was zu Datenverlust führen kann.

In dieser Anleitung wird gezeigt, wie Sie eine Postgresql 12-Master-Standby-Streaming-Replikation unter CentOS 8 einrichten. Wir werden „Replikationsslots für den Standby als Lösung verwenden, um zu verhindern, dass der Master-Server alte WAL-Segmente recycelt, bevor der Standby sie empfangen hat.

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

Testumgebung:

In dieser Anleitung wird davon ausgegangen, dass Sie als Root über SSH eine Verbindung zu Ihren Master- und Standby-Datenbankservern hergestellt haben (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 wesentliche Änderungen an der Replikationsimplementierung und -konfiguration mit sich, wie z. B. die Ersetzung von recovery.conf und die Konvertierung von recovery.conf-Parametern in normale PostgreSQL-Konfigurationsparameter, wodurch die Konfiguration der Cluster-Replikation erheblich vereinfacht wird.

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), auf denen der Master-Server auf Verbindungen von Clients wartet.

In diesem Fall verwenden wir *, was „alle“ bedeutet.

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

Der SQL-Befehl ALTER SYSTEM SET ist eine leistungsstarke Funktion zum Ändern der Konfigurationsparameter eines Servers direkt mit einer SQL-Abfrage. Die Konfigurationen werden in der Datei postgresql.conf.auto im Stammverzeichnis des Datenordners (z. B. /var/lib/pgsql/12/data/) gespeichert und hinzugefügt zu denen, die in postgresql.conf gespeichert sind. Die Konfigurationen im ersteren haben jedoch Vorrang vor denen in den späteren und anderen zugehörigen 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 Clientauthentifizierungskonfigurationsdatei /var/lib/pgsql/12/data/pg_hba.conf ein, wobei das Datenbankfeld auf eingestellt ist Replikation 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 als Nächstes den firewalld-Dienst ausgeführt haben, müssen Sie den Postgresql-Dienst zur 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 eine Basissicherung des Master-Servers vom Standby-Server erstellen; Dies hilft beim Bootstrap 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 das Basis-Backup 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-Tool, um die Basissicherung mit dem richtigen Eigentümer (dem Datenbanksystembenutzer, d. h. Postgres, innerhalb der 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 eine standby.signal-Datei und hängt Verbindungseinstellungen an postgresql.auto.conf unter den Daten an Verzeichnis.
  • -X – wird verwendet, um die erforderlichen Write-Ahead-Protokolldateien (WAL-Dateien) in die Sicherung einzuschließen. 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 Replikationssteckplatzes 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. Ein 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 Replikationsslave wird im Modus „Hot Standby“ ausgeführt, wenn der Parameter hot_standby in postgresql.conf auf „on“ (Standardwert) gesetzt ist und Im Datenverzeichnis ist eine Datei standby.signal vorhanden.

9. Jetzt zurück auf dem Master-Server sollten Sie 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 in der Datei postgresql.auto.conf angehängten Verbindungseinstellungen anzuzeigen, 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-Streaming-Replikation

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

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

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

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

Aus dem Screenshot oben geht hervor, dass die Streaming-Replikation asynchron ist. Im nächsten Abschnitt zeigen wir, 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=# DATENBANK ERSTELLEN tecmint;
[standby]postgres=# \l

Optional: Synchrone Replikation aktivieren

14. Die synchrone Replikation bietet die Möglichkeit, eine Transaktion (oder Daten zu schreiben) gleichzeitig in die Primärdatenbank und die Standby-Datenbank/das Replikat zu übertragen. Es bestätigt nur dann, dass eine Transaktion erfolgreich war, wenn alle durch die Transaktion vorgenommenen Änderungen an einen oder mehrere synchrone Standby-Server übertragen wurden.

Um die synchrone Replikation zu aktivieren, muss auch synchronous_commit auf „on“ gesetzt sein (dies ist der Standardwert, daher sind keine Änderungen erforderlich) und Sie müssen auch den Parameter synchronous_standby_names festlegen auf einen nicht leeren Wert. Für diesen Leitfaden stellen wir es auf „Alle“ ein.

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ärserver erneut abfragen, sollte dieser den Status „Streaming“ und den sync_state von < anzeigensync.

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

Wir sind am Ende dieses Leitfadens angelangt. Wir haben gezeigt, wie man die Master-Standby-Datenbank-Streaming-Replikation für PostgreSQL 12 in CentOS 8 einrichtet. Wir haben auch erläutert, wie Sie die synchrone Replikation in einem PostgreSQL-Datenbankcluster aktivieren.

Es gibt viele Einsatzmöglichkeiten der 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.