Les origines de réplication ont pour but de rendre plus simple les solutions de réplication logique utilisant le décodage logique. Elles fournissent une solution à deux problèmes habituels :
comment suivre la progression de la réplication de manière fiable ;
comment modifier le comportement de la réplication basée sur l'origine d'une ligne ; par exemple pour empêcher les boucles dans les configurations de réplication bidirectionnelle.
Les origines de réplication n'ont que deux propriétés, un nom et un
identifiant. Le nom, qui doit être utilisé pour faire référence à l'origine entre
les systèmes, est une donnée libre de type text
. Il doit être
utilisé d'une façon qui rend improbable les conflits entre des origines de
réplication créées par différentes solutions de réplication, par exemple en
préfixant le nom avec celui de la solution de réplication. L'identifiant est utilisé
seulement pour éviter d'avoir à stocker la version longue dans les
situations où l'espace consommé est critique. Il ne doit jamais être partagé
entre plusieurs systèmes.
Les origines de réplication peuvent être créées en utilisant la fonction
pg_replication_origin_create()
,
supprimées avec la fonction pg_replication_origin_drop()
et consultées dans le catalogue système pg_replication_origin
.
Une partie non triviale de la construction d'une solution de réplication est le suivi de la progression de la réplication d'une manière fiable. Quand le processus d'application des modifications ou l'instance complète meurt, il doit être possible de savoir jusqu'où les données ont été répliquées. Les solutions naïves, comme la mise à jour d'une ligne pour chaque transaction rejouée, ont leurs problèmes, comme une surcharge à l'exécution et une fragmentation de la base de données.
En utilisant l'infrastructure d'origine de réplication, une session peut
être marquée comme rejouant depuis un nœud distant (en utilisant la
fonction
pg_replication_origin_session_setup()
).
De plus, le LSN et l'horodatage de la validation de toute
transaction source peuvent être configurés, transaction par transaction, en
utilisant
pg_replication_origin_xact_setup()
. Si cela est
fait, la progression de la réplication sera conservée de manière pérenne, même
en cas de crash. La progression du rejeu pour toutes les origines de
réplication peut être visualisée dans la vue
pg_replication_origin_status
. Le
progrès d'une origine précise, par exemple lors de la reprise de la
réplication, peut se faire en utilisant la fonction
pg_replication_origin_progress()
pour
toute origine ou la fonction
pg_replication_origin_session_progress()
pour l'origine configurée dans la session courante.
Dans les topologies de réplication plus complexes que la réplication d'un
système vers un autre système, un autre problème peut être
la difficulté d'éviter la réplication de lignes déjà rejouées. Ceci peut mener
à des cycles et une mauvaise efficacité dans la réplication. Les origines de
réplication fournissent un mécanisme optionnel pour reconnaître et empêcher
cela. Lorsqu'elles sont configurées en utilisant les fonctions évoquées
dans le paragraphe précédent, chaque modification et chaque transaction
passée aux fonctions de rappel (callbacks)
des plugins en sortie (voir Section 49.6)
générées par la session sont
tracées avec l'origine de réplication de la session qui les a générées. Ceci
permet de les traiter différemment par le plugin de sortie, et par exemple
d'ignorer toutes les lignes qui ne proviennent pas de l'origine. De plus, la
fonction de rappel
filter_by_origin_cb
peut être utilisée
pour filtrer le flux de modifications de décodage logique basé sur la
source. Bien que moins flexible, le filtre via cette fonction est
considérablement plus efficace que le filtre d'un plugin de sortie.