Bei der Log-Shipping-Methode werden die Datenbankänderungen vom Primary-Server in WAL-Segmenten (Write-Ahead Log) protokolliert, periodisch archiviert und zum Standby-Server via physikalischer Dateiübertragung transferiert. Bei der fortschrittlicheren Methode namens Streaming Replication hingegen werden Änderungen nahezu in Echtzeit repliziert. Hierbei überträgt ein Walsender-Prozess auf dem Primary-Server die WAL-Daten kontinuierlich an einen Walreceiver-Prozess auf dem Standby-Server.

1. Konfiguration des Primary-Servers

1.1 .pgpass erstellen

Die Datei .pgpass, die im Home-Verzeichnis des Benutzers postgres aufbefahrt wird, bietet eine bequeme und sichere Methode zur Verwaltung von Anmeldeinformationen für Datenbankverbindungen und ermöglicht es Benutzern sich automatisch am PostgreSQL-Cluster zu authentifizieren.

Die Datei wird bei der Installation eines PostgreSQL-Clusters nicht mitinstalliert und muss händisch erstellt werden. Es darf ausschließlich der Benutzer postgres auf die Datei lesend und schreibend zugreifen, anderenfalls wird die Datei bei der Authentifizierung ignoriert.

touch ~/.pgpass && chmod 0600 ~/.pgpass

Die Anmeldeinformationen werden nach folgendem Format in der Datei gespeichert:

  • host:port:datenbank:user:passwort
echo '*:5432:*:postgres:postgres' >> ~/.pgpass

Der Stern (*) steht für alle möglichen Werte zulassen.

1.2 pg_hba.conf anpassen

Um den Zugriff auf die Datenbank zu erhalten, muss jeder Benutzer sich zunächst authentifizieren. Die Art der Authentifizierung wird in der Konfigurationsdatei pg_hba.conf festgelegt und geregelt.

Für den Zugriff mit psql und für den Einsatz des pg_basebackup über das Replikationsprotokoll von Postgres ist die Konfigurationsdatei entsprechend der eigenen Anforderungen und der Infrastruktur anzupassen.

Client-Zugriff für alle IP-Adressen aus demselben Subnetz:

  • host all all 192.168.178.0/24 scram-sha-256

Backup und Replikation für alle IP-Adressen aus demselben Subnetz:

  • host replication all 192.168.178.0/24 scram-sha-256

Damit die Konfigurationsänderungen wirksam werden, muss die Datei pg_hba.conf neu eingelesen werden.

pg_ctl -D $PGDATA reload

1.3 Replikation aktivieren

Zum Aufbau des Standby-Servers muss eine vollständige Kopie des PostgreSQL-Clusters, der auf dem Primary-Server läuft, erstellt werden. Diese Aufgabe wird mit pg_basebackup bewerkstelligt, dessen Funktionsweise auf dem Replikationsprotokoll von Postgres beruht.

Das Verhalten von Postgres wird über dessen Konfigurationsdatei postgresql.conf gesteuert. Die Replikation ist in der Standardkonfiguration mit den beiden folgenden Parameteren bereits aktiviert:

  • wal_level=replica
  • max_wal_senders=10

Synchrone bzw. asynchrone Replikation wird über den Parameter synchronous_commit gesteuert. Der Parameter ist in der Standardkonfiguration aktiviert:

  • synchronous_commit=on (off, local, remote_write, remote_apply, oder on)

Um einen Standby-Server als synchron zu konfigurieren, muss dessen Name im folgenden Parameter erfasst sein:

  • syncrhonous_standby_names=”

Die Konfigurationsänderung erfordert einen Neustart des PostgreSQL-Clusters.

1.4 Replication Slot erstellen

Ein physikalischer Replication Slot sorgt dafür, dass auf dem Primary-Server die in den WAL-Segmenten aufgezeichneten Datenbankänderung nicht überschrieben werden, solange diese nicht an den Standby-Server versendet wurden.

Manuell erstellte Replication Slots bieten mehr Kontrolle und Flexibilität bei der Verwaltung, könenn jedoch administrativ aufwendiger sein.

Es gibt zwei Möglichkeiten einen Replication Slot zu erstellen:

1) Auf dem Primary-Server über psql durch einen entsprechenden Funktionsaufruf.

psql -c 'SELECT PG_CREATE_PHYSICAL_REPLICATION_SLOT(''primary_slot'');'

2) Auf dem Standby-Server über pg_basebackup mit der Befehlszeilenoption -S
bei der Erstellung der Kopie des Primary-Clusters.

pg_basebackup -h 192.168.178.54 -p 5432 -U postgres -S primary_slot -D $PGDATA/

Informationen zu den verfügbaren Slots lassen sich über die entsprechende System-View auf der Datenbank erfragen:

psql -c 'SELECT * FROM pg_replication_slots \gx'

Bei der manuellen Erstellung eines physikalischen Slots kann der Name individuell vergeben werden.

2. Konfiguration des Standby-Servers

2.1 Aufbau des Standby-Servers

Auf dem Standby-Server muss bereits ein PostgreSQL-Cluster installiert sein.

Für den Standby-Aufbau ist eine exakte Kopie des PostgreSQL-Clusters vom Primary-Server erforderlich, d.h. beide PostgreSQL-Cluster müssen zueinander binärkompatibel sein und ein und dieselbe Major-Version aufweisen.

Ein mit pg_basebackup erstelltes Backup enthält eine vollständige Kopie des data-Verzeichnisses des PostgreSQL-Servers:

  • Datenbankdateien
  • Konfigurationsdateien
  • WAL-Dateien (Write-Ahead Log)
  • Backup Label und Tablespace Map

Bevor das erstellte Backup auf dem Standby-Server eingespielt werden kann, muss der PostgreSQL-Cluster zunächst angehalten werden:

pg_ctl -D $PGDATA stop

Als Nächstes wird der Inhalt seines data-Verzeichnisses gelöscht:

rm -rf $PGDATA/*

Das Erstellen und Einspielen des Backups auf dem Standby-Server resultiert in einem einzigen Aufruf vonpg_basebackup. Hierbei werden an den pg_basebackup-Aufruf folgende Argumente übergeben:

  • -h: Hostname bzw. IP-Adresse des Primary-Servers
  • -p: Port des PostgreSQL-Clusters auf dem Primary-Server
  • -S: Replication Slot des PostgreSQL-Clusters auf dem Primary-Server
  • -U: Benutzername des Replikationsbenutzers
  • -D: data-Zielverzeichnis auf dem Standby-Server
pg_basebackup -h 192.168.178.54 -p 5432 -S primary_slot -U postgres -D $PGDATA

Der Replikationsbenutzer muss das REPLICATION-Attribut besitzen.

2.2 standby.signal erstellen

Um als Standby zu fungieren, muss der PostgreSQL-Cluster in einen sogenannten permanenten Recovery-Modus überführt werden. Dies wird beim ersten Hochfahren des PostgreSQL-Clusters über die Datei standby.signal initiiert. Hierfür muss die besagte Datei manuell im data-Verzeichnis erstellt werden:

touch $PGDATA/standby.signal

2.3 Verbindungsparameter für Streaming-Replikation konfigurieren

Der Walreceiver-Prozess vom Standby-Server baut eine Verbindung über das Replikationsprotokoll mit dem Walsender-Prozess vom Primary-Server auf. Damit der Verbindungsaufbau zwischen den beiden zustande kommt, müssen in postgresql.conf des Standby-Servers im Parameter primary_conninfo entsprechende Verbindungsparameter zum Primary-Server eingetragen werden:

  • primary_conninfo = ‘host=primary_hostname port=5432 user=postgres passfile=”/var/lib/pgsql/.pgpass”’

Zum Aktivieren der synchronen Replikation muss im primary_conninfo der Parameter application_name des Standby-Servers definiert sein. Dieser Name muss in der synchronous_standby_names-Liste auf dem Primary-Server enthalten sein, um die Standby-Server-Verbindung eindeutig zu identifizieren.

2.4 Automatisierte Konfiguration des Standby-Servers

Durch die Ergänzung des pg_basebackup-Befehls um die Zusatzoption -R kann auf die beiden vorangegangenen Schritte zur manuellen Erstellung der standby.signal-Datei und der Konfiguration von Verbindungsparametern verzichtet werden. Die Konfiguration erfolgt automatisiert und wird in postgresql.auto.conf festgeschrieben. Eine nachträgliche Editierung der postgresql.conf in diesem Zusammenhang ist nicht mehr erforderlich.

pg_basebackup -h 192.168.178.54 -p 5432 -S primary_slot -U postgres -R -D $PGDATA

Sollte der physikalische Replikationslot beim pg_basebackup-Aufruf nicht mitgegeben worden sein, muss er nachträglich in postgresql.conf in der Sekiton Standby Servers eingetragen werden:

  • primary_slot_name=’primary_slot’

2.5 Aktivierung des hot_standby-Parameters

Der hot_standby=on sorgt dafür, dass auf den Standby-Server lesend zugegriffen werden kann. Ist die Einstellung off, wird das Lesen unterbunden.

3. Standby-Server in Betrieb nehmen

Nach Abschluss der Konfiguration und der Erstellung einer Kopie des PostgreSQL-Clusters vom Primary-Server, kann der Standby-Server hochgefahren werden.

pg_ctl -D $PGDATA start

Der neue Standby-Server befindet sich im Recovery-Modus, wenn folgende Funktion ein true zurückliefert.

psql -c 'SELECT PG_IS_IN_RECOVERY();'

Der Status der Replikation lässt sich sowohl auf dem Primary-Server als auch auf dem Standby-Server über die entsprechenden System-Views des PostgreSQL-Clusters ermitteln.

Der Status der Replikation für alle verbundenen Standby-Server wird auf dem Primary-Server in pg_stat_replication überwacht.

psql -c 'SELECT * FROM pg_stat_replication;'

Der Status des Walreceiver-Prozesses wird auf dem Standby-Server in pg_stat_wal_receiver überwacht.

psql -c 'SELECT * FROM pg_stat_wal_receiver;'

Die Einrichtung der Streaming-Replikation in PostgreSQL erfordert sorgfältige Planung und Konfiguration. Wenn alle Schritte korrekt ausgeführt werden, bietet diese Lösung eine robuste Methode zur Sicherstellung der Verfügbarkeit und Integrität der Datenbank. Im Gegensatz zu der Log-Shipping-Methode findet eine nahezu Echtzeit-Replikation der Daten statt. Dies reduziert die Latenzzeit erheblich und sorgt dafür, dass der Standby-Server immer auf dem neuen Stand ist.

Blog Mykola Kumanikin

Mykola Kumanikin

Mykola Kumanikin arbeitet als Consultant für die Proventa AG. Sein Tätigkeitsumfeld umfasst Software-Testing, Ticketmanagement und seit Kurzem Datenbankarchitekturen mit PostgreSQL. Seine fachlichen Erfahrungen sammelte er in den unterschiedlichen Projekten in der Telekommunikationsbranche.