Documentation PostgreSQL 14.22 » Programmation serveur » Tracer la progression de la réplication

Précédent | Niveau supérieur | Suivant
49.10. Support du Two-phase commit pour le décodage logique | Sommaire | Partie VI. Référence

## Chapitre 50. Tracer la progression de la réplication

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 OID. 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'OID 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.