Un abonnement est le côté aval de la réplication logique. Le nœud où un abonnement a été défini est nommé abonné. Un abonnement définit la connexion à une autre base de données et un ensemble de publications (une ou plus) auxquelles l'abonné veut souscrire.
La base de données abonnée se comporte comme n'importe quelle base de données d'une instance PostgreSQL et peut être utilisée comme éditeur pour d'autres bases de données en définissant ses propres publications.
Un nœud abonné peut avoir plusieurs abonnements si besoin. Il est possible de définir plusieurs abonnements entre une même paire éditeur-abonné. Dans ce cas, il faut faire attention à ce que les objets des publications auquelles l'abonné a souscrit ne se chevauchent pas.
Chaque abonnement recevra les changements par un slot de réplication (voir Section 27.2.6). Des slots de réplications supplémentaires peuvent être nécessaires pour la synchronisation initiale des données d'une table contenant des données pré-existantes et ils seront supprimés à la fin de la synchronisation des données.
Un abonnement de réplication logique peut être un serveur standby pour de
la réplication synchrone (voir Section 27.2.8).
Le nom du serveur standby correspond par défaut au nom de l'abonnement. Un
nom alternatif peut être indiqué avec le paramètre
application_name dans les informations de connexion à
l'abonnement.
Les abonnements sont sauvegardés par pg_dump si
l'utilisateur courant a des droits de super-utilisateur. Si ce n'est
pas le cas, un message d'avertissement est renvoyé et les abonnements ne sont pas
sauvegardés. En effet, les informations d'abonnements contenues dans
pg_subscription ne sont pas consultables par
des utilisateurs dotés de droits moins importants.
Un abonnement est ajouté en utilisant CREATE
SUBSCRIPTION. Il peut être arrêté/repris à n'importe quel
moment en utilisant la commande ALTER
SUBSCRIPTION et il peut être supprimé par la commande
DROP
SUBSCRIPTION.
Quand un abonnement est supprimé puis recréé, les informations de synchronisation sont perdues. Cela signifie que les données doivent être resynchronisées ensuite.
La définition d'un schéma n'est pas répliquée, et les tables publiées doivent exister sur la base abonnée. Seules des tables standards peuvent accueillir des données répliquées. Par exemple, il n'est pas pas possible de répliquer dans une vue.
La correspondance entre les tables de l'éditeur et de l'abonné est réalisée en utilisant le nom entièrement qualifié de la table. La réplication entre des tables portant un nom différent sur la base abonnée n'est pas supportée.
La correspondance sur les colonnes d'une table se fait aussi par nom.
L'ordre des colonnes dans la table sur le serveur abonné ne correspond pas
forcément à l'ordre sur le serveur publieur. Les types de données n'ont pas
non plus besoin de correspondre, à partir du moment où la représentation
textuelle de la donnée puisse être convertie vers le type de données cible.
Par exemple, vous pouvez répliquer d'une colonne de type
integer vers une colonne de type bigint. La table
cible peut aussi avoir des colonnes supplémentaires non fournies par la
table publiée. Ce type de colonne sera rempli avec la valeur par défaut
fournie dans la définition de la table cible.
Comme présenté plus tôt, chaque abonnement (actif) reçoit les changements depuis un slot de réplication du serveur distant (publication).
Des slots de synchronisation de tables supplémentaires sont normalement
temporaires, créés en interne pour réaliser la synchronisation initiale
des tables et supprimés automatiquement quand elles ne sont plus
nécessaires. Ces slots de synchronisation de table ont des noms générés
automatiquement :
« pg_%u_sync_%u_%llu »
(paramètres: oid de la souscription,
relid de la table, sysid
pour l'identifiant du système).
Normalement, le slot de réplication distant est créé
automatiquement en utilisant la commande
CREATE SUBSCRIPTION et il est supprimé
automatiquement en utilisant la commande
DROP SUBSCRIPTION.
Dans certaines situations, il peut être utile ou nécessaire de
manipuler les abonnements ainsi que les slots de réplication
sous-jacents de façon séparées. Voici quelques exemples :
Lorsqu'en créant un abonnement, le slot de réplication
correspondant existe déjà. Dans ce cas, l'abonnement peut être
créé en utilisant l'option create_slot = false
pour réaliser l'association avec le slot existant.
Lorsqu'en créant un abonnement, le serveur distant n'est pas
disponible ou dans un état indéfini. Dans ce cas, l'abonnement
peut être créé en utilisant l'option connect = false.
Le serveur distant ne sera jamais contacté. C'est la méthode
utilisée par pg_dump.
Le slot de réplication distant devra alors être créé manuellement
avant que l'abonnement puisse être activé.
Lorsqu'on supprime un abonnement et que le slot de réplication doit
être conservé, par exemple lorsqu'une base abonnée est
déplacée vers un serveur différent et sera activée depuis cette
nouvelle localisation.
Dans ce cas, il faut dissocier le slot de réplication de
l'abonnement correspondant en utilisant la commande
ALTER SUBSCRIPTION avant de supprimer
l'abonnement.
Lorsque l'on supprime un abonnement et que le serveur distant n'est
pas joignable. Dans ce cas, il faut aussi dissocier le slot de
réplication de l'abonnement correspondant en utilisant
ALTER SUBSCRIPTION avant de supprimer
l'abonnement.
Si l'instance distante n'existe plus, aucune action supplémentaire
n'est nécessaire. Si, par contre, l'instance distante est
simplement temporairement injoignable, le slot de réplication (et tout
slot de synchronisation de table restant)
devrait être supprimé manuellement, sinon l'instance va
persévérer à conserver ses fichiers WAL jusqu'à saturation de
l'espace disque disponible. Ces cas doivent être traités avec
beaucoup de précautions.
