PostgreSQLLa base de données la plus sophistiquée au monde.
Documentation PostgreSQL 15.6 » Administration du serveur » Réplication logique » Architecture

31.7. Architecture

La réplication logique démarre en copiant un instantané des données sur la base de publication. Une fois cette étape réalisée, les modifications sur la base de publication sont envoyées à la base de données abonnée au fil de l'eau. La base abonnée applique les modifications sur les données dans l'ordre dans lequel les validations ont été effectuées sur la base éditeur de manière à ce que la cohérence transactionnelle soit respectée pour les publications vis à vis de tous les abonnements.

La réplication se construit de façon similaire à la réplication physique en flux (Streaming Replication, voir Section 27.2.5). Ceci est implémenté par les processus « walsender » et « apply ». Le processus walsender démarre le décodage logique (décrit dans la section Section 55.5) des fichiers WAL et charge le plugin de décodage logique standard (pgoutput). Ce plugin transforme les changements lus depuis les fichiers WAL vers le protocole de réplication logique (voir Section 55.5) et filtre les données en fonction des spécificités des publications. Les données sont envoyées au fil de l'eau au processus apply, qui met en relation les données vers les tables locales et applique les changements individuels au moment où ils sont reçus, dans le bon ordre transactionnel.

Le processus apply sur l'instance de la base abonnée fonctionne toujours avec le paramètre session_replication_role défini à la valeur replica. Ceci signifie que, par défaut, les triggers et règles ne se déclencheront pas sur un abonné. Les utilisateurs peuvent choisir en option d'activer les triggers et les règles sur une table en utilisant la commande ALTER TABLE et les clauses ENABLE TRIGGER et ENABLE RULE.

Le processus apply de la réplication logique déclenche actuellement des triggers de ligne, et non pas des triggers de requêtes. Néanmoins, la synchronisation initiale des tables est implémentée comme une commande COPY, ce qui peut déclencher les triggers INSERT en mode ligne et requête.

31.7.1. Instantané initial

Les données initiales présentes dans des tables abonnées sont photographiées et copiées dans une instance parallèle qui utilise un type particulier de processus apply. Ce processus va créer son propre slot de réplication et copier les données existantes. Dès que la copie est terminée, le contenu de la table deviendra visible aux autres processus. Une fois les données existantes copiées, le processus passe en mode de synchronisation, qui assure que la table est amenée vers un état synchronisé avec le processus apply principal, ceci en transférant toutes les modifications survenues pendant la copie initiale des données, réalisée avec le système de réplication logique standard. Lors de cette phase de synchronisation, les changements sont appliqués et validés dans le même ordre que sur le publieur. Une fois la synchronisation terminée, le contrôle de la réplication de la table est rendu au processus apply principal et la réplication continue telle quelle.

Note

Le paramètre de publication publish affecte uniquement les opérations DML qui seront répliquées. La synchronisation initiale des données ne prend pas ce paramètre en compte lors de la copie des données existantes de la table.