Résoudre un conflit de réplication logique (disable_on_error, SKIP)

Commande

-- 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;

Ce que fait la commande

Lorsqu'une erreur comme une clé dupliquée, une ligne manquante ou un problème de permission arrête l'apply sur le subscriber : disable_on_error désactive automatiquement la souscription ; corrigez les données en conflit puis faites ENABLE, ou utilisez SKIP pour ignorer toute la transaction distante identifiée par le LSN 'finished at' du journal.

Quand l'utiliser

Lorsque le worker d'apply échoue et redémarre sans cesse à cause d'écritures directes sur le subscriber, d'une copie initiale incomplète ou d'écritures bidirectionnelles.

Attention

SKIP abandonne aussi les changements non conflictuels de cette transaction et les deux côtés divergent définitivement ; préférez corriger les données, et comparez la table après un SKIP. Tant que le conflit n'est pas résolu, le slot du publisher continue d'accumuler du WAL. Empêchez par des privilèges les écritures applicatives sur les tables du subscriber.