Konflikt in der logischen Replikation lösen (disable_on_error, SKIP)

Befehl

-- 1) Prevent a failing apply worker from looping forever:
ALTER SUBSCRIPTION sub_app SET (disable_on_error = true);
-- 2) Find the finish LSN of the conflicting transaction in the subscriber log:
--    CONTEXT: ... in transaction 749, finished at 0/5035378
-- 3a) Preferred: fix/delete the conflicting row on the subscriber, then re-enable:
ALTER SUBSCRIPTION sub_app ENABLE;
-- 3b) Or skip the whole remote transaction (NONE of its changes are applied on the subscriber):
ALTER SUBSCRIPTION sub_app SKIP (lsn = '0/5035378');
ALTER SUBSCRIPTION sub_app ENABLE;
SELECT subname, subenabled, subskiplsn FROM pg_subscription;

Was es tut

Stoppt ein Fehler wie ein doppelter Schlüssel, eine fehlende Zeile oder ein Rechteproblem das Apply auf dem Subscriber: disable_on_error deaktiviert die Subscription automatisch; entweder die konfliktverursachenden Daten korrigieren und ENABLE ausführen, oder mit SKIP die gesamte Remote-Transaktion überspringen, die über die LSN 'finished at' im Log identifiziert wird.

Wann einsetzen

Wenn der Apply-Worker wegen direkter Schreibvorgänge auf dem Subscriber, einer unvollständigen initialen Kopie oder bidirektionaler Schreibvorgänge fehlschlägt und ständig neu startet.

Vorsicht

SKIP verwirft auch die nicht konfliktbehafteten Änderungen dieser Transaktion, und beide Seiten laufen dauerhaft auseinander; korrigiere lieber die Daten und vergleiche die Tabelle nach einem SKIP. Bis der Konflikt gelöst ist, sammelt der Slot auf dem Publisher weiter WAL an. Verhindere Anwendungsschreibzugriffe auf Subscriber-Tabellen über Privilegien.