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
undTablespace 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 inpostgresql.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.