PostgreSQL – Logische Replikation

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:

1. Architektur
2. Grundlegende Syntax
3. Ein Beispiel

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:

• Es kann keine selektive Replikation durchgeführt werden oder ein Teil der Datenbank kann nicht repliziert werden.
• Es kann nicht zwischen zwei verschiedenen Hauptversionen repliziert werden.
• Es können keine Schreibvorgänge auf dem Standby-Server ausgeführt werden.
• Es kann nicht zwischen verschiedenen Plattformen (z. B. Linux und Windows) repliziert werden.

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 Architektur

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.

Grundlegende Syntax

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:

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:

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:

1. Jeder Abonnent kann mehrere Veröffentlichungen abonnieren und jede Veröffentlichung kann Änderungen für mehrere Abonnenten veröffentlichen.
2. Um Tabellen zu einer vorhandenen Publikation hinzuzufügen oder daraus zu entfernen, kann der ‘Alter publication’-Befehl verwendet werden.
3. Das Datenbankschema und die DDL-Definitionen können noch nicht auf den Abonnenten repliziert werden. Die veröffentlichten Tabellen müssen auf dem Abonnenten vorhanden sein.
4. Die replizierte Tabelle muss eine reguläre Tabelle sein – keine Ansichten, materialisierten Ansichten, Partitionsstammtabellen oder Fremdtabellen.
5. Die Tabelle sollte im Herausgeber und Abonnenten denselben vollständig qualifizierten Namen haben.
6. Die Spaltennamen müssen übereinstimmen, aber die Reihenfolge der Spalten in der Abonnententabelle spielt keine Rolle. Darüber hinaus kann eine abonnierte Tabelle dieselbe oder mehrere Spalten enthalten.
7. Die Replikation von Sequenzdaten und großen Objekten wird noch nicht unterstützt.

Ein Beispiel

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:

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.

Ü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.