PostgreSQL ist ein leistungsstarkes und funktionsreiches Verwaltungssystem für relationale Datenbanken (RDBMS). Es ist kostenlos und quelloffen und wird seit 1996 entwickelt. Postgres bietet verschiedene Möglichkeiten zum Archivieren und Replizieren von Daten, von denen eine die Streaming-Replikation ist. In diesem Modus verwaltet eine primäre (Master-) Instanz die aktive Hauptdatenbank und führt Operationen aus. Die sekundäre (Slave-)Instanz kopiert alle Änderungen von der primären und behält eine identische Kopie der aktiven Datenbank bei. Der sekundäre Server kann auch schreibgeschützte Abfragen akzeptieren. Wenn der primäre Server ausfällt, kann der sekundäre Server den Standby-Modus verlassen und als neuer Master fungieren (dies wird als Failover bezeichnet).
Die PostgreSQL-Replikation basiert normalerweise auf Write-Ahead-Protokollierung (WAL), dem Prozess der Protokollierung von Datenänderungen, bevor sie auf die Festplatte geschrieben werden. Diese WAL-Datensätze werden dann entweder als Dateien auf einen zweiten Knoten kopiert (dateibasierter Protokollversand) oder direkt zwischen den Knoten gestreamt (Streaming-Replikation). Letzteres reduziert in den meisten Fällen die Verzögerung, bis Änderungen am Master-Knoten vom Standby-Knoten empfangen werden.
Das Problem bei der Verwendung der Streaming-Replikation ohne dateibasierten Protokollversand besteht darin, dass der sekundäre Server möglicherweise einige WAL-Einträge verpasst, wenn der primäre sie zu früh verwirft. Eine Reihe von Konfigurationsparametern kann dieses Risiko verringern, ist jedoch oft mit unnötigen Speicherkosten verbunden. Die Lösung sind Replikationsslots, eine von Postgres bereitgestellte Funktion, die sicherstellt, dass der primäre Server WAL-Einträge erst verwirft, nachdem sie vom Standby-Knoten empfangen wurden.
Wir werden eine Streaming-Replikation mit Replikationsslots auf zwei Debian 10-Knoten einrichten.
Anforderungen
- Zwei identische Debian 10-Instanzen.
- Root-Zugriff auf beide Instanzen.
- Die Umgebungsvariable $EDITOR sollte auf beiden Instanzen gesetzt werden.
Schritt 1:PostgreSQL installieren
Aktualisieren Sie beide Knoten und starten Sie sie neu:
apt update apt upgrade -y reboot
Installieren Sie Postgres auf beiden Knoten und stellen Sie sicher, dass PostgreSQL aktiviert ist und ausgeführt wird:
apt install -y postgresql systemctl enable --now [email protected]
HINWEIS:Wenn Sie PostgreSQL aktualisieren, ist es gemäß ihrer Dokumentation die sicherere Option, zuerst den Standby zu aktualisieren.
Schritt 2:Erstkonfiguration
Standardmäßig lauscht PostgreSQL nur auf der Loopback-Schnittstelle und ist nicht von außen zugänglich. Ändern Sie die Listen-Adresse auf beiden Knoten, indem Sie postgresql.conf:
bearbeiten$EDITOR /etc/postgresql/11/main/postgresql.conf
Suchen Sie die folgende Zeile:
#listen_addresses = 'localhost'
Ändern Sie es in:
listen_addresses = 'node_ip_address,127.0.0.1'
Wenn beide Knoten dasselbe lokale Netzwerk verwenden, können Sie private Adressen für node_ip_address verwenden, obwohl Postgres nicht über das Internet zugänglich ist. Verwenden Sie andernfalls öffentliche Adressen.
Speichern Sie die Änderung und starten Sie beide Instanzen neu:
systemctl restart [email protected]
Schritt 3:Master-Konfiguration
Dieser Schritt betrifft nur den Primär-/Master-Server.
Öffnen Sie das Postgres-Terminal:
sudo -u postgres psql
Der Standby-Knoten verwendet einen Benutzer, um sich mit dem Master zu verbinden. Erstellen Sie es:
postgres=# CREATE ROLE replicator LOGIN REPLICATION ENCRYPTED PASSWORD 'replicator_password';
Erstellen Sie dann einen Replikationsslot und beenden Sie:
postgres=# SELECT * FROM pg_create_physical_replication_slot('replicator');
postgres=# \q
Der Einfachheit halber werden die Replikationsrolle und der Slot beide als "Replikator" bezeichnet, obwohl sie nicht identisch sein müssen.
Erstellen Sie als Nächstes einen Eintrag in pg_hba.conf, damit der Benutzer des Replikators eine Verbindung vom Standby zum Master herstellen kann. Öffnen:
$EDITOR /etc/postgresql/11/main/pg_hba.conf
Fügen Sie am Ende die folgende Zeile hinzu:
host replication replicator standby_ip_address/32 md5
Starten Sie die Masterinstanz neu:
systemctl restart [email protected]
Schritt 4:Basissicherung
Die Befehle in diesem Schritt sollten auf dem Sekundär-/Slave-Server ausgeführt werden.
Stoppen Sie zunächst Postgres auf dem sekundären Knoten:
systemctl stop [email protected]
Sichern Sie das alte Datenverzeichnis:
mv /var/lib/postgresql/11/main/ /var/lib/postgresql/11/main.bak
Verwenden Sie den folgenden Befehl, um das Datenverzeichnis des Masters auf den Slave zu klonen:
pg_basebackup -h master_ip_address -U replicator -D /var/lib/postgresql/11/main/ -P --password --slot replicator
Sie werden nach einem Passwort gefragt. Geben Sie das Passwort ein, das Sie für die Replikatorrolle während ihrer Erstellung auf dem Master gewählt haben. Erteilen Sie nach Abschluss der Übertragung dem Postgres-Benutzer die Eigentümerschaft des Datenverzeichnisses:
chown -R postgres:postgres /var/lib/postgresql/11/main
Schritt 5:Standby-Konfiguration
Dieser Schritt betrifft nur den Sekundär-/Slave-Server.
Aktivieren Sie den Hot-Standby-Modus in postgresql.conf:
$EDITOR /etc/postgresql/11/main/postgresql.conf
Suchen Sie die folgende Zeile und kommentieren Sie sie aus:
#hot_standby = on
Erstellen Sie die Datei recovery.conf im Postgres-Datenverzeichnis:
$EDITOR /var/lib/postgresql/11/main/recovery.conf
Standby-Modus aktivieren:
standby_mode = 'on'
Legen Sie die Replikationsverbindungsparameter mit den auf dem Master erstellten Anmeldeinformationen fest:
primary_conninfo = 'host=master_ip_address port=5432 user=replicator password=replicator_password'
Legen Sie den Namen des Replikations-Slots fest, den Sie auf dem Master erstellt haben:
primary_slot_name = 'replicator'
Legen Sie den Pfad zu einer Failover-Triggerdatei fest:
trigger_file = '/var/lib/postgresql/11/main/failover.trigger'
Wenn der Parameter trigger_file gesetzt ist, verlässt Postgres den Standby-Modus und startet den normalen Betrieb als primärer Server, wenn diese Triggerdatei erstellt wird. Dieser Parameter ist nicht erforderlich.
Erteilen Sie nach dem Erstellen von recovery.conf dem postgres-Benutzer die Eigentümerschaft:
chown postgres:postgres /var/lib/postgresql/11/main/recovery.conf
Sie können Postgres jetzt starten:
systemctl start [email protected]
Es befindet sich jetzt im Standby-Modus und sollte jede neue Transaktion replizieren.
Testen
Replikation testen
Führen Sie zum Testen der Replikation eine beliebige Schreibaktion auf dem Master aus. Erstellen Sie beispielsweise eine neue Datenbank auf dem Master:
sudo -u postgres psql -c "CREATE DATABASE replitest"
Warten Sie ein paar Sekunden und listen Sie dann die Datenbanken auf dem Slave auf:
sudo -u postgres psql -c "\l"
Sie sollten sehen, dass die Replitest-Datenbank tatsächlich vom Standby-Server repliziert wurde:
List of databases
Name | Owner | Encoding | Collate | Ctype | Access privileges
-----------+----------+----------+-------------+-------------+-----------------------
postgres | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 |
replitest | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 |
template0 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/postgres +
| | | | | postgres=CTc/postgres
template1 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/postgres +
| | | | | postgres=CTc/postgres
(4 rows) Failover testen
HINWEIS:Das hier gezeigte Testen des Failover erfordert das Zurücksetzen des Standby-Servers nach dem Failover.
Da sich Postgres im Standby-Modus befindet, sollten Sie vor dem Failover keine Schreibvorgänge auf dem sekundären Knoten ausführen können. Führen Sie beispielsweise den folgenden Befehl aus:
sudo -u postgres psql -c "CREATE DATABASE test"
Der Befehl sollte fehlschlagen:
ERROR: cannot execute CREATE DATABASE in a read-only transaction
Um ein Failover zu signalisieren, erstellen Sie die Triggerdatei, die in recovery.conf
angegeben isttouch /var/lib/postgresql/11/main/failover.trigger
Warten Sie einige Sekunden und versuchen Sie dann, einen Schreibvorgang durchzuführen. Zum Beispiel:
sudo -u postgres psql -c "CREATE DATABASE test2"
Da Postgres nicht mehr als Standby betrieben wird, wird der Vorgang erfolgreich sein. Postgres benennt auch Ihre recovery.conf-Datei in recovery.done um und löscht die Trigger-Datei.
Um wieder in den Standby-Modus zu wechseln, stoppen Sie Postgres auf dem (ehemaligen) sekundären Knoten:
systemctl stop [email protected]
Setzen Sie das Datenverzeichnis zurück:
mv /var/lib/postgresql/11/main/ /var/lib/postgresql/11/main.2.bak pg_basebackup -h master_ip_address -U replicator -D /var/lib/postgresql/11/main/ -P --password --slot replicator chown -R postgres:postgres /var/lib/postgresql/11/main
Und erstellen Sie recovery.conf neu:
cp /var/lib/postgresql/11/main.2.bak/recovery.done /var/lib/postgresql/11/main/recovery.conf
Starten Sie abschließend Postgres neu:
systemctl start [email protected]
Die sekundäre Instanz befindet sich jetzt wieder im Standby-Modus. Möglicherweise möchten Sie die Replikation an dieser Stelle erneut testen.
Abschluss
Entfernen Sie alle unnötigen Datenbanken auf dem Master-Knoten, zum Beispiel:
sudo -u postgres psql postgres=# DROP DATABASE replitest;
Und löschen Sie die alten Datenverzeichnisse auf Ihrem Standby-Knoten:
rm /var/lib/postgresql/11/main.bak -r rm /var/lib/postgresql/11/main.2.bak -r