PostgreSQLLa base de données la plus sophistiquée au monde.
Documentation PostgreSQL 15.7 » Internes » Protocole Frontend/Backend » Logical Streaming Replication Protocol

55.5. Logical Streaming Replication Protocol

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.

55.5.1. Paramètres de la réplication logique en flux

En utilisant la commande de réplication logique START_REPLICATION, le plugin pgoutput accepte les options suivantes :

proto_version

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.

publication_names

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.

binary

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.

messages

Option booléenne pour activer l'envoi de messages qui sont écrits par pg_logical_emit_message.

streaming

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.

two_phase

Option booléenne pour activer les transactions en deux phases. Il est requis d'activer au minimum la version3 du protocole.

55.5.2. Messages du protocole de réplication logique

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.

55.5.3. Flot des messages du protocole de réplication logique

À 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.