Cette section décrit le protocole de réplication logique qui consiste en un
flux de message démarré par la commande START_REPLICATION
SLOT nom_slot
LOGICAL.
Le protocole de réplication logique en flux se base sur les primitives du protocole de réplication physique en flux.
Le décodage logique PostgreSQL accepte des plugins
de sortie. pgoutput est le plugin standard utilisé par la
réplication logique native.
En utilisant la commande de réplication logique
START_REPLICATION, le plugin pgoutput
accepte les options suivantes :
La version du protocole. Actuellement, les versions 1,
2 et 3 sont supportées. Une option
valide est requise.
La version 2 n'est supportée qu'à partir de la version
14 et permet la transmission de transactions volumineuses non terminées.
La version 3 n'est supportée qu'à partir de la version
15 et permet l'utilisation de la validation en deux phases (2PC) avec la
réplication logique.
Liste séparée par des virgules contenant les noms de publication auxquelles s'abonner (recevoir les modifications). Les noms individuels de publication sont traités comme des noms d'objets standard et peuvent être mis entre guillemets si nécessaire. Il est requis d'indiquer au moins un nom de publication.
Option booléenne pour utiliser le mode de transfert binaire. Le mode binaire est plus rapide que le mode texte mais un peu moins robuste.
Option booléenne pour activer l'envoi de messages qui sont écrits par
pg_logical_emit_message.
Option booléenne pour activer l'envoi en flux des transactions en cours. Il est requis d'activer au minimum la version 2 du protocole.
Option booléenne pour activer les transactions en deux phases. Il est requis d'activer au minimum la version3 du protocole.
Les messages individuels du protocole sont discutés dans les sous-sections suivantes. Les messages individuels sont décrits dans Section 55.9.
Tous les message haut niveau du protocole commencent avec un octet de type de message. Bien que représenté dans le code comme un caractère, c'est en fait 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 haut niveau du protocole 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 se déplacent
uniquement du backend vers le client.
Le protocole de réplication logique envoie les transactions individuelles l'une après l'autre. Cela signifie que tous les messages entre une paire de messages Begin et Commit appartiennent à la même transaction. De façon similaire, tous les messages entre une paire de messages Begin Prepare et Prepare appartiennent à la même transaction. Il envoie aussi les changements de grosses transactions en cours entre une paire de messages Stream Start et Stream Stop. Le dernier lot d'une telle transaction contient un message Stream Commit ou Stream Abort.
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 origine indique que la transaction provient d'un autre nœud de réplication. Comme un nœud de réplication peut être à peu près tout dans le cas du protocole de réplication logique, le seul identifiant est le nom de l'origine. C'est au client de gérer ceci. Le message Origin est toujours envoyé avant tout message DML dans la transaction.
Chaque message DML contient un OID de relation, identifiant la relation concernée. Avant le premier message DML pour un OID de relation donné, un message Relation sera envoyé, décrivant le schéma de cette relation. Après cela, un nouveau message Relation sera envoyé si la définition de la relation a changé depuis l'envoi du dernier message Relation. (Le protocole suppose que le client est capable de se rappeler de cette méta donnée pour toutes les relations impliquées.)
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 cet OID localement, donc aucune donnée supplémentaire n'est nécessaire. Pour les OID de type utilisateur, un message Type sera envoyé avant le message Relation pour fournir le nom du type associé à cet OID. De ce fait, un client qui a besoin d'identifier spécifiquement les types des colonnes d'une relation devrait placer en cache le contenu des messages Type, et consulter ce cache pour vérifier si l'OID du type y est défini. Dans le cas contraire, il sera possible de rechercher localement l'OID du type.
