Logische Replikation in PostgreSQL: Publikationen, Subskriptionen und der Unterschied zur Streaming-Replikation

Worum es geht

Physische (Streaming-)Replikation sendet Write-Ahead-Log-Einträge an einen Standby, der sie blockweise wiedergibt; die Standby-Dokumentation hält fest, dass die Hardwarearchitektur gleich sein muss und dass Log-Shipping zwischen unterschiedlichen Hauptversionen im Allgemeinen nicht möglich ist. Logische Replikation repliziert laut dem zitierten Kapitel Datenobjekte und ihre Änderungen anhand ihrer Replikatidentität (in der Regel ein Primärschlüssel) in einem Publish-and-Subscribe-Modell: Ein Publisher definiert eine Publikation über Tabellen (wahlweise beschränkt auf INSERT, UPDATE, DELETE oder TRUNCATE, mit Zeilenfiltern und Spaltenlisten), ein Subscriber erstellt eine Subskription, ein Anfangs-Snapshot kopiert die vorhandenen Zeilen, und spätere Änderungen werden in Commit-Reihenfolge angewendet, was die Dokumentation transaktionale Replikation nennt. Jede Subskription bezieht Änderungen über einen Replikations-Slot auf dem Publisher.

Warum es wichtig ist

Ein Streaming-Standby ist eine vollständige Kopie für Failover und Lese-Skalierung; er kann nicht beschrieben werden und keine Auswahl treffen. Logische Replikation überträgt eine Teilmenge von Tabellen an eine Datenbank, die eine andere Hauptversion, eine andere Plattform, ein Konsolidierungsziel für Analysen oder ein Subscriber sein kann, der auch eigene Tabellen hält. Die Anwendungsfallliste des Kapitels nennt unter anderem die Replikation zwischen Hauptversionen, was ein Upgrade mit einer Umschaltzeit von Sekunden ermöglicht.

So wird es angewendet

• Jeder veröffentlichten Tabelle einen Primärschlüssel geben; eine Tabelle ohne geeigneten Schlüssel benötigt REPLICA IDENTITY FULL, was die Dokumentation als Rückfalllösung mit ineffizienten Zeilensuchen auf dem Subscriber beschreibt.
• Das Schema zunächst von Hand kopieren (pg_dump --schema-only): Die Seite zu den Einschränkungen hält fest, dass das Datenbankschema und DDL-Befehle nicht repliziert werden, und empfiehlt, additive Schemaänderungen zuerst auf dem Subscriber anzuwenden.
• Sequenzen einplanen: Sequenzdaten werden nicht repliziert, daher die Sequenzen des Subscribers vor einer Umschaltung über die aktuellen Werte des Publishers hinaus setzen.
• Den Slot im Auge behalten. Ein ausgefallener Subscriber behält seinen Slot, und der Slot hält WAL auf dem Publisher zurück, bis die Platte voll ist; max_slot_wal_keep_size begrenzt die Aufbewahrung, um den Preis, dass ein zu weit zurückgefallener Slot ungültig wird.
• Replizierte Tabellen auf dem Subscriber als nur lesbar behandeln. Die Seite zu Konflikten hält fest, dass eingehende Änderungen auch dann angewendet werden, wenn die Zeile lokal geändert wurde, und dass eingehende Daten, die eine Constraint verletzen (etwa eine lokale Zeile mit demselben eindeutigen Schlüssel), die Replikation stoppen, bis von Hand aufgelöst wird.

Stolpersteine

Large Objects werden nicht repliziert, und Views, materialisierte Views und Fremdtabellen können nicht veröffentlicht werden. Eine Schemaänderung auf dem Publisher, die die Tabelle des Subscribers nicht akzeptieren kann, stoppt die Replikation, bis der Subscriber korrigiert ist. Logische Replikation ist kein Backup: Ein DELETE oder TRUNCATE auf dem Publisher wird originalgetreu übernommen.