In diesem Beitrag wird die logische Replikation in PostgreSQL erläutert. Es werden die Unterschiede zwischen physischer oder binärer Replikation und logischer oder transaktionaler Replikation überprüft. Anschließend werden die folgenden Komponenten der logischen Replikation beschrieben:
Postgres hat die physische (binäre) Replikation ab PostgreSQL 9.0 eingeführt. Bei der physischen Replikation wird jede Änderung im Master über die WAL (Write-Ahead-Protokollierung) gestreamt und auf den Standby-/Zielserver angewendet. Bestimmte Dinge sind jedoch bei Verwendung der physischen Replikation nicht möglich:
PostgreSQL 10 implementiert die logische Replikation, die die oben genannten Einschränkungen der physischen Replikation berücksichtigt und die Möglichkeit eröffnet, neue Replikationsbereiche zu nutzen. Bei der logischen Replikation, auch als Transaktionsreplikation bezeichnet, erhält der Abonnent zunächst eine Kopie des replizierten Datenbankobjekts vom Herausgeber und ruft alle nachfolgenden Änderungen, die in Echtzeit auftreten, an demselben Objekt ab.
Die logische Replikation folgt einem Publish- und Subscribe-Modell. In einem Herausgeberknoten wird eine Veröffentlichung erstellt, bei der es sich um eine Reihe von Änderungen gegenüber einer Tabelle oder einer Gruppe von Tabellen handelt. In einem Abonnentenknoten wird ein Abonnement erstellt, das eine oder mehrere Veröffentlichungen abonnieren kann.
Die Replikation beginnt mit dem Kopieren eines Snapshots der Veröffentlichungsdatenbank auf den Abonnenten. Dies wird auch als Tabellensynchronisationsphase bezeichnet. Es können mehrere Tabellensynchronisations-Worker erzeugt werden, um den Zeitaufwand in dieser Phase zu verringern. Es kann jedoch nur einen Synchronisations-Worker pro Tabelle geben. Sobald der Kopiervorgang abgeschlossen ist, werden die nachfolgenden Änderungen im Herausgeberknoten an den Abonnentenknoten gesendet, sobald sie in Echtzeit auftreten. Die vom Publisher übermittelten Änderungen werden vom Abonnenten angewendet, wodurch die Transaktionskonsistenz erhalten bleibt.
Für ein minimales logisches Replikationssetup muss nur wal_level = logical
geändert werden. Dies weist den Server an, zusätzliche Informationen in der WAL zu speichern, um binäre Änderungen in logische umzuwandeln. Sobald dies erledigt ist, können wir eine Veröffentlichung mit dem folgenden Befehl erstellen:
CREATE PUBLICATION my_pub FOR ALL TABLES;
Anstatt alle Tabellen zu veröffentlichen, können wir auch eine Reihe von Tabellen angeben, die veröffentlicht werden sollen. Darüber hinaus kann eine Veröffentlichung die veröffentlichten Änderungen auf eine beliebige Kombination von INSERT-
, UPDATE-
, DELETE–
und TRUNCATE-
Operationen beschränken. Um jedoch UPDATE–
und DELETE-
Operationen replizieren zu können, muss eine veröffentlichte Tabelle eine Replikatidentität haben, damit die geänderten Zeilen im Abonnenten identifiziert werden können. INSERT-
Vorgänge können unabhängig von der Replikatidentität ausgeführt werden.
Weitere Infos zu CREATE PUBLICATION
finden Sie hier.
Sobald die Veröffentlichungen erstellt sind, können wir Abonnements im Abonnentenknoten erstellen:
CREATE SUBSCRIPTION my_sub
CONNECTION 'host=<...> port=5432 user=<...> dbname=<...>'
PUBLICATION my_pub;
Dadurch wird ein neues Abonnement my_sub
für die aktuelle Datenbank hinzugefügt, das die logischen Änderungen aus der Veröffentlichung my_pub
empfängt. Wenn der Befehl ausgeführt wird, wird ein logischer Replikations-Worker erzeugt, der die logischen Änderungen vom Herausgeber erhält. Auf der Herausgeberseite wird ein WAL-Sender-Prozess erzeugt, der dafür verantwortlich ist, die WAL einzeln zu lesen, die Änderungen zu dekodieren und diese Änderungen an den jeweiligen Abonnenten zu senden.
Weitere Infos zu CREATE SUBSCRIPTION
finden Sie hier.
Einige wichtige Punkte sollten beachtet werden, bevor die logische Replikation in Versionen vor PostgreSQL 12 verwendet wird:
‘Alter publication’
-Befehl verwendet werden.Richten wir die logische Replikation für eine Tabelle ein. Zuerst erstellen wir, mit folgendem Befehl, eine einfache Tabelle und fügen eine Zeile ein:
Als Nächstes richten wir, mit folgendem Befehl, eine Veröffentlichung für dieselbe Tabelle ein:
create publication my_pub for table t1;
Mit folgendem Befehl können Sie, sobald die Veröffentlichung erstellt wurde, ein Abonnement erstellen. Bitte beachten Sie, dass wir den Herausgeber und den Abonnenten auf demselben Host erstellt haben.
CREATE TABLE t1(a int primary key, b int);
CREATE SUBSCRIPTION my_sub
CONNECTION 'host=localhost port=54321 dbname=postgres'
PUBLICATION my_pub;
Überprüfen Sie nun, ob die vorhandene Zeile repliziert wurde:
Anschließend überprüfen wir, ob die laufenden Änderungen repliziert werden. Dazu fügen wir eine weitere Zeile in den Herausgeber ein und überprüfen diese im Abonnenten:
Nachdem Sie nun wissen, wie Sie eine logische Replikation erstellen können, bietet es sich an, sich damit zu beschäftigen, wie die Datenkonsistenz einer logischen Replikation untersucht werden kann.
In unserem nächsten Artikel werden wir darauf eingehen, welche Probleme hier entstehen können und wie Sie damit umgehen können.
Kontaktieren Sie uns gerne über das
Kontaktformular und vereinbaren ein unverbindliches
Beratungsgespräch mit unseren Berater:innen zur
Bedarfsevaluierung. Gemeinsam optimieren wir Ihre
Umgebung und steigern Ihre Performance!
Wir freuen uns auf Ihre Kontaktaufnahme!