Documentation PostgreSQL 14.22 » Internes » Protocole client/serveur » Protocole de réplication logique en flux

Précédent | Niveau supérieur | Suivant
53.4. Protocole de réplication en continu | Sommaire | 53.6. Types de données des messages

## 53.5. Protocole de réplication logique en flux

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.

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

En utilisant la commande `START_REPLICATION`, `pgoutput` accepte les paramètres suivants :

proto_version

  Version de protocole. Actuellement, les versions `1` et `2` sont supportées. Une version valide est requise. La version `2` est seulement suportée pour la version serveur 14 et ultérieure, et elle permet un flux de larges transactions.

publication_names

  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.

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.

### 53.5.2. Messages du protocole de réplication logique

Les messages individuels du protocole de réplication sont discutés dans les sous-sections suivantes. Les messages individuels sont décrits dans Section 53.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.

### 53.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 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. Il envoie aussi les changements des larges transactions entre une paire de messages de diffusion Start et Stop. La dernière diffusion de tels transactions contient le 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 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.