La réplication logique se comporte de la même manière pour les opérations DML
dans le sens où les données seront mises à jour même si la modification a été
faite en local sur la base abonnée. Si les données entrantes entrainent des
violations de contrainte d'intégrité, la réplication s'arrête. Cela sera
référencé comme un conflit. Lorsque l'on réplique des
opérations UPDATE
ou DELETE
, les
données manquantes ne produiront pas de conflit et des opérations de la sorte
seront simplement évitées.
Les opérations de réplication logique sont réalisées avec les droits du
propriétaire de la souscription. Les échecs de droit sur les tables cibles
causeront des conflits de réplication, tout autant que l'activation de politiques de sécurité au niveau ligne sur
des tables cibles et pour lesquels le propriétaire de la souscription est
sujet des politiques de sécurité, sans chercher si une politique rejetterait
habituellement les opérations INSERT
,
UPDATE
, DELETE
ou
TRUNCATE
en cours de réplication. Cette restriction sur
les politiques de sécurité niveau ligne pourrait être supprimée dans une
prochaine version de PostgreSQL.
Lorsqu'un conflit entraine une erreur, cela stoppe la réplication ; Le conflit devra être résolu manuellement par un utilisateur. Des informations détaillées concernant le conflit seront disponibles dans les journaux applicatifs de l'instance abonnée.
La résolution peut être réalisée, soit en changeant les données ou les droits sur la base abonnée pour qu'elles ne soient plus en conflit avec les données entrantes ou en évitant les transactions qui sont en conflit avec les données existantes. Quand un conflit produit une erreur, la réplication ne peut pas continuer et le processus worker de la réplication logique émet un message du type suivant dans les journaux applicatifs de l'abonné :
ERROR: duplicate key value violates unique constraint "test_pkey" DETAIL: Key (c)=(1) already exists. CONTEXT: processing remote data for replication origin "pg_16395" during "INSERT" for replication target relation "public.test" in transaction 725 finished at 0/14C0378
Le LSN de la transaction qui contient le changement violant la contrainte et
le nom d'origine de réplication peuvent être trouvés à partir du journal
applicatif du serveur (LSN 0/14C0378 et origine de réplication
pg_16395
dans le cas ci-dessus). La transaction qui a
produit le conflit peut être ignorée en utilisant l'instruction
ALTER SUBSCRIPTION ... SKIP
avec le LSN final (LSN
0/14C0378). Le LSN final pourrait être un LSN sur lequel la transaction est
validée ou préparée sur le publieur. La transaction peut aussi être ignorée
en appelant la fonction pg_replication_origin_advance()
.
Avant d'utiliser cette fonction, la souscription doit être désactivée
temporairement soit par ALTER SUBSCRIPTION ... DISABLE
soit en utilisant l'option disable_on_error
de la souscription. Ensuite, vous pouvez utiliser la fonction
pg_replication_origin_advance()
avec
node_name
(pg_16395
) et le LSN
suivant du LSN final (0/14C0379). La position actuelle des origines peut être
trouvée dans la vue système pg_replication_origin_status
.
Merci de noter qu'ignorer la transaction complète inclut d'ignorer des
changements qui pourraient ne pas violer des contraintes. Ceci peut rendre
l'abonné incohérent très facilement.
Quand le mode streaming
vaut parallel
, le LSN final des transactions en échec peut ne pas être
journalisé. Dans ce cas, il peut être nécessaire de changer le mode
de flux (streaming) à on
ou off
et provoquer
les même conflits encore pour que le LSN final des transactions échouées soit écrit dans
le journal du serveur. Pour l'utilisation du LSN final, veuillez vous reférer à
ALTER SUBSCRIPTION ... SKIP
.