Cette section décrit le protocole de réplication logique, qui correspond au
flot de messages lancé par la commande de réplication
START_REPLICATION SLOT nom_slot LOGICAL.
Le protocole de réplication logique en flux est construit sur les primitives du protocole de réplication physique en flux.
Le décodage logique de PostgreSQL supporte des
plugins de sortie. pgoutput est celui utilisé en standard
pour la réplication logique native.
En utilisant la commande START_REPLICATION,
pgoutput accepte les paramètres suivants :
Version du protocole. Actuellement, seule la version 1
est supportée. Une version valide est requise.
Liste de noms de publications, séparés par des virgules, pour souscription (récupération des modifications). Les noms de publication individuels sont traités comme des noms d'objet standard et peuvent être mis entre guillemets si nécessaire. Il est requis d'indiquer au moins un nom de publication.
Les messages individuels du protocole de réplication sont discutés dans les sous-sections suivantes. Les messages individuels sont décrits dans Section 52.9.
Tous les messages de niveau supérieur commencent avec un octet de type de message. Bien qu'ils soient représentés dans le code comme un caractère, il s'agit d'un octet signé sans encodage associé.
Comme le protocole de réplication en flux fournit une longueur de message, il n'est pas nécessaire que les messages de niveau supérieur embarquent une longueur dans leur en-tête.
À l'exception de la commande START_REPLICATION et des
messages de progression du rejeu, toutes les informations passent du
serveur vers le client.
Le protocole de réplication logique envoie les transactions individuelles une par une. Cela signifie que tous les messages entre une paire de messages Begin et Commit appartiennent à la même transaction.
Chaque transaction envoyée contient zéro ou plusieurs messages DML (Insert, Update, Delete). Dans le cas d'une configuration en cascade, elle peut aussi contenir des messages Origin. Le message d'origine indiquait que la transaction avait pour origine un nœud de réplication différent. Comme le nœud de réplication dans le cas d'une réplication logique peut provenir de n'importe où, le seul identificateur est le nom de l'origine. C'est de la responsabilité du receveur de gérer cette information si nécessaire. Le message Origin est toujours envoyé avant tout message DML dans la transaction.
Chaque message DML contient un OID de relation, identifiant la relation du publieur. Avant le premier message DML pour un OID de relation donné, un message Relation sera envoyé, décrivant le schéma de cette relation. Ensuite, un nouveau message Relation sera envoyé si la définition de la relation a été modifié depuis l'envoi du dernier message Relation. (Le protocole suppose que le client est capable de se rappeler cette méta-données pour autant de relations que nécessaire.)
Les messages Relation identifient les types des colonnes par leur OID. Dans le cas d'un type interne, il est supposé que le client peut rechercher l'OID du type localement, donc aucune donnée supplémentaire n'est envoyée. Pour un OID d'un type non interne, un message Type sera envoyé avant le message Relation pour fournir le nom du type de données associé avec cet OID. De ce fait, un client qui a besoin d'identifier spécifiquement les types des colonnes de la relation devrait mettre en cache le contenu des messages Type, et consulter ce cache en premier lieu pour savoir l'OID du type y est défini. Sinon, il faut chercher localement l'OID du type.
