Documentation PostgreSQL 9.5.25 > Programmation serveur > Tracer la progression de la réplication | |
Support de la réplication synchrone pour le décodage logique | Référence |
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 garder trace en toute certitude de la progression de la réplication.
Comment modifier le comportement de réplication basé 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 ont uniquement 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 difficile les conflits entre origines de réplication créés 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 récupérées dans le catalogue système pg_replication_origin.
Une partie non triviale de la construction d'une solution de réplication est la conservation de la progression de la réplication d'une manière sûre. 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. Une solution naïve, comme la mise à jour d'une ligne pour chaque transaction rejouée, a des 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 à partir d'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 c'est fait, la progression de la réplication sera conservée de manière sûre, 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. Une progression individuelle de l'origine, 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 au niveau de 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 pouvant survenir est qu'il est difficile d'éviter la réplication de lignes déjà rejouées. Ceci peut amener des cycles et des inefficacités 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 référencées dans le paragraphe précédent, chaque modification et chaque transaction passée aux fonctions de rappel des plugins en sortie (voir Section 46.6, « Plugins de sortie de décodage logique ») 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é. 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é 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.