Erfahren Sie mehr über die Streaming-Replikationsfunktion von PostgreSQL und verwenden Sie sie.
Die Streaming-Replikationsfunktion von PostgreSQL gibt es seit einigen Jahren. Sie kann verwendet werden, um replizierte PostgreSQL-Clusterkonfigurationen auf verschiedene Arten und für verschiedene Zwecke einzurichten. Wie einfach und vielseitig diese Funktion ist!
Eine kleine Theorie
Die Grundlage der Streaming-Replikation ist die Möglichkeit, Write Ahead Logs(WALs) zu versenden und anzuwenden.
WALs werden in fast allen modernen RDBMS-Systemen verwendet, um dauerhafte und atomare Transaktionen bereitzustellen. Einfach ausgedrückt, wird jede Transaktion, die in der Datenbank ausgeführt wird, zuerst als WAL-Datei ausgeschrieben und dann auf die tatsächlichen Tabellendatendateien auf der Festplatte angewendet. WAL-Dateien sind streng sequenziell. Dies macht die WAL-Dateisequenz zu einem "Replay-Protokoll" von Änderungen.
Dies bedeutet, dass Sie, wenn Sie alle Änderungen replizieren müssen, die auf einem Datenbankknoten stattfinden, Sie nur die WAL-Dateien kopieren müssen, während sie erstellt werden, und sie nacheinander auf einen anderen Knoten anwenden. Auf diese Weise erhalten Sie einen weiteren Datenbankknoten mit Identischem Inhalt wie der ursprüngliche. Mit anderen Worten, Sie können einen Slave-Knoten erhalten.
Wie kopieren wir also die WAL-Dateien? Es handelt sich buchstäblich um Dateien, die von einem Computer auf einen anderen kopiert werden müssen, sodass Sie entweder Skripts einrichten können, die dies tun, oder die Streaming-Replikationsfunktion verwenden, um eine Verbindung herzustellen und die Dateien vom Master abzuziehen.
Was passiert, wenn ich die Dateien auf mehrere Knoten kopiere? Am Ende haben Sie zwei (oder mehr) identische Slaves, die jeweils vom selben Master repliziert werden. Das ist ein gültiges und nützliches Szenario.
Kann ich die Daten an den Slaves ändern? Das kannst du nicht. Die Replikation, die wir hier beschrieben haben, ist unidirektional – Sie können die WALs von einem Master-Knoten zu einem Slave-Knoten abrufen, aber nicht umgekehrt. Die Streaming-Replikation unterstützt keine bidirektionalen oder Multi-Master-Replikations-Setups. Es gibt 3rd-Party-Lösungen, die Ihnen dabei helfen können.
Kann ich die Daten von den Slaves lesen? Ja, das ist der Konsens Der Slave wird dann als "Hot Standby" bezeichnet. Solche Setups werden häufig zum Ausführen analytischer Workloads verwendet, ohne die Last auf einem Live-Master zu erhöhen.
Ich möchte eine Echtzeitreplikation auf andere Knoten. Kein Problem. Slave-Knoten können "synchron" sein. Wenn der Master aufgefordert wird, eine Transaktion festzuschreiben, wartet er, bis alle synchronen Slaves die WAL-Dateien für diese Transaktion gezogen haben (und auf die Festplatte geschrieben haben). Wenn Sie mit MongoDB vertraut sind, ähnelt dies einem "Schreibproblem" von mehr als 1.
Werden sich die WAL-Dateien nicht weiter anhäufen? Sie werden es tun, wenn Sie Postgres nicht sagen, wann sie aufräumen sollen. Sie können diese Dateien nach Anzahl und/oder Gesamtgröße begrenzen. Der Master muss offensichtlich an ihnen festhalten, bis alle Slaves sie aufheben. Einzelne WAL-Dateien haben eine feste Größe von 16 MB und leben unter $PGDATA /pg_xlog.
Grundlegende Replikation
Wenn du dich überwältigt fühlst, versuche, einen Slave aufzustellen, um zu sehen, wie einfach es ist! Wir gehen davon aus, dass Sie eine laufende PostgreSQL-Installation auf der IP 10.0.0.10 haben und dass Sie einen Slave bei 10.0.0.11 einrichten, wobei beide PostgreSQL 9.5.4 ausführen.
Master-Einrichtung
Werfen Sie zunächst einen Blick auf die Einstellungen des Masters (postgresql.conf) und aktualisieren Sie sie bei Bedarf (und starten Sie den Server neu, damit die Änderungen wirksam werden):
# Die WAL-Ebene sollte hot_standby oder logisch sein.
wal_level = hot_standby
# Erlauben Sie bis zu 8 Standbys und Backup-Prozessen, um gleichzeitig eine Verbindung herzustellen.
max_wal_senders = 8
# Behalten Sie WAL-Dateien im Wert von 1 GB. Passen Sie dies abhängig von Ihrer Transaktionsrate an.
max_wal_size = 1GB
Als Nächstes müssen wir einen Benutzer erstellen. Dieser Streaming-Replikationsclient im Slave-Knoten stellt als dieser Benutzer eine Verbindung mit dem Master her.
$ sudo -u postgres psql
psql (9.5.4)
Type "help" for help.
postgres=# create user repluser replication;
CREATE ROLE
postgres=# \q
Erlauben Sie diesem Benutzer in pg_hba.conf, eine Verbindung zur Replikation herzustellen.
# TYPE DATABASE USER ADDRESS METHOD
host replication repluser 10.0.0.11/32 trust
Der Benutzer repluser ist ein normaler Postgres-Benutzer, also zögern Sie nicht, Ihre Standard-Authentifizierungspraktiken zu verwenden. Denken Sie daran, neu zu laden (sudo systemctl reload postgresql), damit die Änderungen wirksam werden.
Slave-Einrichtung
Wir müssen den Slave mit einem backup der Datenbanken des Masters initialisieren. Wir werden dies direkt vom Slave aus tun. Beachten Sie, dass bei diesem Vorgang alle Daten auf dem Slave gelöscht werden.
Zuerst stoppen wir den Slave:
$ sudo systemctl stop postgresql
Als nächstes erstellen wir die Sicherung:
$ pg_basebackup -h 10.0.0.10 -U repluser -Ft -x -D – > /tmp/backup.tar
Dies stellt eine Verbindung zum Master als dem Benutzer her, den wir gerade erstellt haben, und erstellt eine Sicherungskopie der Datenbanken des Masters und schreibt sie in /tmp/ backup.tar. Lassen Sie uns dies nun wiederherstellen:
$ export DATADIR=/var/lib/postgresql/9.5/main
$ sudo rm -rf $DATADIR/*
$ sudo -u postgres tar x -v -C $DATADIR -f /tmp/backup.tar
$ rm /tmp/backup.tar
Wir müssen eine Datei namens recovery.conf im Datenverzeichnis des Slaves erstellen. Dadurch wird dem Slave gesagt, wie er eine Verbindung zum Master herstellen soll.
$ sudo tee $DATADIR/recovery.conf <<EOR
# This tells the slave to keep pulling WALs from master.
standby_mode = on
# This is how to connect to the master.
primary_conninfo = 'host=10.0.0.10 user=repluser'
EOR
$ sudo chown postgres:postgres $DATADIR/recovery.conf
Und schließlich ermöglichen wir dem Slave, als Read Replica zu dienen. Aktivieren Sie dazu hot_standby in postgresql.conf:
hot_standby = on
Jetzt sind wir bereit, den Slave zu starten:
$ sudo systemctl start postgresql
Der Slave sollte gestartet werden, die Streaming-Replikation starten und in den Hot-Standby-Modus wechseln. In der Protokolldatei /var/log/postgresql /postgresql-9.5-main.logsollten ähnliche Protokolleinträgevorhandensein:
[25471-2] LOG: entering standby mode
[25471-3] LOG: redo starts at 0/3000760
[25471-4] LOG: consistent recovery state reached at 0/3000840
[25471-5] LOG: invalid record length at 0/3000840
[25470-1] LOG: database system is ready to accept read only connections
[25475-1] LOG: started streaming WAL from primary at 0/3000000 on timeline 1
Glückwunsch! Sie haben nun einen Slave-Knoten eingerichtet, der die Streaming-Replikation verwendet, um mit dem Master synchron zu bleiben.
So verhält sich der Slave, wenn Sie versuchen, Änderungen vorzunehmen:
postgres=# select pg_is_in_recovery();
pg_is_in_recovery
——————-
t
(1 row)
postgres=# create database testme;
ERROR: cannot execute CREATE DATABASE in a read-only transaction
Mehrere Slaves
Sie können die Schritte für das Slave-Setup auf einem anderen Knoten wiederholen, um einen anderen Slave aufzubringen. Stellen Sie sicher, dass max_wal_senders hoch genug ist, um alle Slaves und den gelegentlichen Sicherungs- oder Verwaltungsprozess, der eine Verbindung zum Master herstellt, aufzunehmen.
SynchroneRe REplikation
Um die synchrone Replikation mit einem weiteren Standby zu aktivieren, stellen Sie zunächst sicher, dass jeder Standby einen Namen hat. Sie können den Namen wie application_name im Parameter primary_conninfo in der recovery.conf des Standby-Modus wie folgt angeben:
# In the file /var/lib/postgresql/9.5/main/recovery.conf, include the
# application name in the primary_conninfo:
primary_conninfo = 'host=10.0.0.10 user=repluser application_name=pluto'
Sobald jeder Standby einen Namen hat, auf den sich der Master beziehen kann, können Sie die postgresql.conf des Masters bearbeiten:
# Wait for standbys to finish writing out WALs to disk, before returning from
# the commit.
synchronous_commit = remote_write
# These are the standbys that need to acknowledge the write. You can also use
# '*' to indicate all the standbys.
synchronous_standby_names = 'pluto'
Natürlich nehmen synchrone Commits mehr Zeit in Anspruch, bieten aber eine erhöhte Sicherheit gegen Abstürze des Masterservers.
Cascading Replikation
Anstatt zwei Slaves vom selben Master zu replizieren, können Sie einen Slave von einem anderen replizieren. Dies wird normalerweise als "kaskadierende Replikation" bezeichnet.
Ein Hot Standby kann selbst als Master dienen und es ermöglichen, ihn zu replizieren. Außer den Master-Einstellungen wie max_wal_senders und pg_hba.conf-Authentifizierung muss nichts extra konfiguriert werden.
Die kaskadierende Replikation ist immer asynchron.
Slave Promotion
Slaves können zu Mastern befördert werden. Dies kann durch Ausführen des folgenden Befehls erfolgen:
$ sudo pg_ctlcluster 9.5 main promote
Sie können auch einen Dateinamen (genannt "Triggerdatei") in recovery.conf angeben:
# In the file /var/lib/postgresql/9.5/main/recovery.conf, include a
# trigger file name:
trigger_file = '/tmp/pg-trigger-failover-now'
Postgres führt ein Failover durch und stuft den Slave herauf, wenn es feststellt, dass diese Datei erstellt wurde.
Nach einem Failover wird die Datei recovery.conf in recovery.done umbenannt. Der Inhalt der Datei wird danach von Postgres nicht mehr berücksichtigt und berücksichtigt.
Stellen Sie vor dem Failover sicher, dass der Slave-Knoten eine identische Konfiguration (einschließlich pb_hba.conf mit den richtigen IPs) mit dem vorhandenen Master hat. Außerdem sollte nach einem erfolgreichen Failover der alte Master außer Betrieb genommen werden ("shoot the other node in the head"). Anwendungen sollten nicht versuchen, mit dem pensionierten Master zu sprechen.
Weiterführende Literatur
Das entsprechende Kapitel in der PostgreSQL-Dokumentation ist der beste Ort, um weiter zu graben. Die Wiki-Seite hat auch mehr Links und Tipps.
Es gibt auch weitere Rückkopplungsmechanismen zwischen einem Slave und einem Master, die wir hier nicht behandelt haben. Dazu gehören Replikationssteckplätze und andere Konfigurationsoptionen.
Auf dieser Seite finden Sie einen guten Überblick über andere Replikationslösungen.