La réplication se construit de façon similaire à la réplication physique en
flux (Streaming Replication, voir Section 26.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 54.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 54.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
, qui produit les effets habituels sur les triggers
et les contraintes.
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.
The initial data in existing subscribed tables are snapshotted and copied in parallel instances of a special kind of apply process. These special apply processes are dedicated table synchronization workers, spawned for each table to be synchronized. Each table synchronization process will create its own replication slot and copy the existing data. As soon as the copy is finished the table contents will become visible to other backends. Once existing data is copied, the worker enters synchronization mode, which ensures that the table is brought up to a synchronized state with the main apply process by streaming any changes that happened during the initial data copy using standard logical replication. During this synchronization phase, the changes are applied and committed in the same order as they happened on the publisher. Once synchronization is done, control of the replication of the table is given back to the main apply process where replication continues as normal. 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.
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.
If a table synchronization worker fails during copy, the apply worker
detects the failure and respawns the table synchronization worker to
continue the synchronization process. This behaviour ensures that
transient errors do not permanently disrupt the replication setup. See
also wal_retrieve_retry_interval
.