Réplication logique dans PostgreSQL : publications, abonnements et différences avec la réplication en continu

Ce que c'est

La réplication physique (en continu) envoie les enregistrements du journal des écritures anticipées (write-ahead log) vers un standby qui les rejoue bloc par bloc ; la documentation du standby indique que l'architecture matérielle doit être la même et que l'expédition de journal entre différentes versions majeures n'est en général pas possible. La réplication logique, selon le chapitre cité, réplique des objets de données et leurs changements en se basant sur leur identité de réplication (généralement une clé primaire) dans un modèle de publication et d'abonnement : un serveur de publication définit une publication sur des tables (éventuellement limitée à INSERT, UPDATE, DELETE ou TRUNCATE, avec des filtres de lignes et des listes de colonnes), un abonné crée un abonnement, un instantané initial copie les lignes existantes, et les changements ultérieurs sont appliqués dans l'ordre des validations (commit), ce que la documentation appelle réplication transactionnelle. Chaque abonnement consomme les changements via un slot de réplication sur le serveur de publication.

Pourquoi c'est important

Un standby en réplication en continu est une copie complète pour le basculement et la montée en charge en lecture ; il ne peut pas recevoir d'écritures et ne peut pas être sélectif. La réplication logique transporte un sous-ensemble de tables vers une base de données qui peut être d'une version majeure différente, d'une plateforme différente, une cible de consolidation pour l'analytique, ou un abonné qui possède aussi ses propres tables. La liste des cas d'usage du chapitre inclut la réplication entre versions majeures, ce qui rend possible une mise à niveau avec quelques secondes de bascule.

Comment l'appliquer

• Donner à chaque table publiée une clé primaire ; une table sans clé adaptée nécessite REPLICA IDENTITY FULL, que la documentation décrit comme un repli avec des recherches de ligne inefficaces côté abonné.
• Copier d'abord le schéma à la main (pg_dump --schema-only) : la page des restrictions indique que le schéma de la base de données et les commandes DDL ne sont pas répliqués, et recommande d'appliquer d'abord les changements de schéma additifs à l'abonné.
• Prévoir le cas des séquences : les données de séquence ne sont pas répliquées, donc avant un basculement, positionner les séquences de l'abonné au-delà des valeurs actuelles du serveur de publication.
• Surveiller le slot. Un abonné arrêté conserve son slot, et le slot retient le WAL sur le serveur de publication jusqu'à ce que le disque se remplisse ; max_slot_wal_keep_size borne la rétention au prix d'invalider un slot qui prend trop de retard.
• Traiter les tables répliquées comme en lecture seule côté abonné. La page sur les conflits indique que les changements entrants sont appliqués même si la ligne a été modifiée localement, et que des données entrantes violant une contrainte (par exemple une ligne locale avec la même clé unique) arrêtent la réplication jusqu'à résolution manuelle.

Pièges

Les objets larges (large objects) ne sont pas répliqués, et les vues, vues matérialisées et tables distantes ne peuvent pas être publiées. Un changement de schéma sur le serveur de publication que la table de l'abonné ne peut pas accepter arrête la réplication jusqu'à ce que l'abonné soit corrigé. La réplication logique n'est pas une sauvegarde : un DELETE ou un TRUNCATE sur le serveur de publication est appliqué fidèlement.