PostgreSQLLa base de données la plus sophistiquée au monde.
Documentation PostgreSQL 10.22 » Internes » Protocole client/serveur » Protocole de réplication logique en flux

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

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

La commande START_REPLICATION de réplication logique accepte les paramètres suivants :

proto_version

Version du protocole. Actuellement, seule la version 1 est supportée.

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.

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

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

Chaque transaction envoyée contient zéro ou pluseurs 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 noeud de réplication différent. Comme le noeud de réplication dans le cas d'une réplication logique peut provenir de n'importe pù, 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.