Logische Replikation

Die logische Replikation ist eine Methode zur Replikation von Datenobjekten und ihren Änderungen auf der Grundlage der Replikationsidentität der Objekte und ihrer Änderungen. Bei der logischen Replikation wird ein Veröffentlichungs - und Abonnementmodell verwendet, bei dem ein oder mehrere Abonnenten eine oder mehrere Veröffentlichungen auf einem Herausgeberknoten abonnieren. Abonnenten rufen Daten aus den Publikationen ab, die sie abonnieren.

Mit der logischen Replikation haben Sie eine genaue Kontrolle sowohl über die Datenreplikation als auch über die Sicherheit. Sie können die logische Replikation in den folgenden Anwendungsfällen verwenden:

• Replikation zwischen verschiedenen Hauptversionen von PostgreSQL

• Replikation zwischen PostgreSQL-Instanzen auf verschiedenen Plattformen (z. B. Linux auf Windows)

Architektur

Die folgenden Workflow-Schritte zeigen, wie eine logische Replikationsarchitektur funktioniert:

1. Sie erstellen einen Snapshot der Daten in der Herausgeberdatenbank und kopieren diese Daten in die Abonnentendatenbank.

2. Die Änderungen in den Herausgeberdatenbanken werden in Echtzeit an den Abonnenten gesendet.

3. Der Abonnent wendet die Daten in derselben Reihenfolge an wie der Herausgeber, sodass die Transaktionskonsistenz für Veröffentlichungen innerhalb eines einzigen Abonnements gewährleistet ist.

Eine Publikation kann auf einer primären Instanz (Herausgeber) definiert werden. Eine Publikation besteht aus einer Reihe von Änderungen, die anhand einer Tabelle oder einer Gruppe von Tabellen generiert wurden. Sie können Änderungen aus einer Kombination von INSERT-, UPDATE-, DELETE- und TRUNCATE-Vorgängen auswählen. Standardmäßig werden all diese Änderungen in die Abonnentendatenbank repliziert. Dies steht im Gegensatz zur physischen Replikation, bei der exakte Blockadressen für eine byte-by-byte Replikation verwendet werden.

In einer veröffentlichten Tabelle muss REPLICA IDENTITY so konfiguriert sein, dass die UPDATE- und DELETE-Operationen repliziert werden, sodass die zu aktualisierenden oder zu löschenden Zeilen auf Abonnentenseite identifiziert werden können. In den meisten Fällen wird die Replikatidentität entweder durch einen Primärschlüssel oder einen eindeutigen Schlüssel bestimmt. Wenn kein Primärschlüssel vorhanden ist und Sie keinen erstellen können, können Sie die Replikatidentität auf festlegen. full Das bedeutet, dass die gesamte Zeile zum Schlüssel wird. Es wird empfohlen, die Replikatidentität full als letzten Ausweg auf festzulegen, da diese Einstellung ineffizient ist.

Ein Abonnement ist die nachgelagerte Seite der logischen Replikation. Der Knoten, auf dem ein Abonnement definiert ist, wird als Abonnent bezeichnet. Ein Abonnement definiert die Verbindung zu einer anderen Datenbank und einer Gruppe von Veröffentlichungen (eine oder mehrere), die es abonnieren möchte.

Konfigurationseinstellungen

Die folgenden Konfigurationen sind für Herausgebereinstellungen erforderlich:

• Stellen Sie wal_level auf einlogical.

• Wird so eingestelltmax_replication_slots, dass mindestens die Anzahl der Abonnements, von denen erwartet wird, dass sie eine Verbindung herstellen, und einige Reserveslots für die Tabellensynchronisierung aufnehmen.

• Legen max_wal_senders Sie fest, max_replication_slots ob und wie viele physische Replikate vorhanden sind.

Die folgenden Konfigurationen sind für Abonnenteneinstellungen erforderlich:

• Legen max_replication_slots Sie fest, dass die geringste Anzahl von Abonnements berücksichtigt wird, die Sie dem Abonnenten hinzufügen möchten, und einige Reserveabonnements für die Tabellensynchronisierung.

• Legen max_logical_replication_workers Sie fest, dass mindestens die Anzahl der Abonnements und einige Reserve-Worker für die Tabellensynchronisierung berücksichtigt werden.

• max_worker_processesMindestens auf (max_logical_replication_workers+1) gesetzt.

Jedes Abonnement empfängt Änderungen über einen Replikationssteckplatz.

Die folgenden Schritte zeigen, wie eine logische Replikation durchgeführt wird:

1. Erstellen Sie einen Herausgeber, indem Sie den Befehl CREATE PUBLICATION für eine Gruppe von Tabellen (die Teil der Replikation sein werden) in der Quelldatenbank verwenden.

2. Erstellen Sie einen Abonnenten mit dem Befehl CREATE SUBSCRIPTION und geben Sie dann bei der Erstellung des Abonnenten die Veröffentlichungsdetails an.

3. Das anfängliche Laden der Daten beginnt automatisch von der Quelldatenbank zur Zieldatenbank.

4. Die Änderungsdaten, die von Replikationssteckplätzen erfasst werden, werden in die Zieldatenbank repliziert.

5. Verwenden Sie pg_stat_replication (eine Katalogtabelle), um den Status der Replikation zu überprüfen. Verwenden Sie pg_stat_replication_slots, um den Replikationsslot zu überprüfen.

Weitere Informationen finden Sie im Beitrag Verwenden von logischer Replikation zur Replikation von verwaltetem Amazon RDS for PostgreSQL und Amazon Aurora to Self-managed PostgreSQL im AWS-Datenbank-Blog.

Einschränkungen

Wir empfehlen Ihnen, die folgenden Einschränkungen der logischen Replikationsmethode zu berücksichtigen, bevor Sie mit der Migration beginnen:

• Die logische Replikation weist derzeit die meisten Einschränkungen und Funktionslücken auf.

• Bei der logischen Replikation können keine Operationen mit Data Definition Language (DDL), Sequenz und große Objekte repliziert werden. Eine Aktion zum Kürzen (die für eine Tabelle mit einem Fremdschlüssel gilt) muss verknüpfte Tabellen in demselben Abonnement enthalten.

Weitere Informationen zu den Einschränkungen der logischen Replikation finden Sie unter 31.6. Einschränkungen in der PostgreSQL-Dokumentation.