![](/head/replicationlogique.png)
Nous vous présentions la réplication logique native dans cet article de Sébastien Lardière.
Depuis son intégration à PostgreSQL en version 10, cette fonctionnalité n’a cessé d'être améliorée. Dans cet article, nous vous proposons de faire la chronologie des changements.
Il est possible d’extraire les fonctionnalités ajoutées par chaque version majeure de PostgreSQL via la matrice de fonctionnalités.
Apport de la version 11
- Prise en compte de la commande
TRUNCATE
. Auparavant seules les commandesINSERT
,UPDATE
etDELETE
étaient répliquées.
Apports de la version 12
- Possibilité de copier les slots de réplication logique, à des fins de debug ou pour sélectionner d’autres plugins de sortie.
Apports de la version 13
- Ajout de la réplication des tables partitionnées ;
- Ajout du paramètre
logical_decoding_work_mem
afin de contrôler la quantité de mémoire allouée à un processuswalsender
. Cela détermine la quantité de modifications conservée en mémoire avant l'écriture sur disque (valeur par défaut à 64MB) ; - Ajout du paramètre
max_slot_wal_keep_size
(valeur par défaut à -1, pas de limite) afin de limiter le volume total de fichiers WAL que les slots de réplication peuvent conserver dans le répertoirepg_wal
. Cela permet de limiter la saturation disque, avec le risque, toutefois, de rendre inopérante la réplication connectée à ce slot, si des WAL nécessaires n’ont pas été conservés.
Apports de la version 14
- Ajout du streaming des longues transactions en cours au lieu d’attendre la fin des transactions. Cela permet de réduire le retard d’application des modifications ;
- Possibilité de transférer les données au format binaire au lieu de texte pour les types de données applicables ;
- Utilisation de plusieurs transactions au lieu d’une seule lors de la phase de synchronisation des tables. Cela permet d’accélérer la recopie initiale des données ;
- Amélioration du décodage des transactions préparées afin d’initier le décodage au moment du
prepare time
et non plus seulement ducommit
; - Ajout de la vue
pg_stat_replication_slots
pour reporter l’activité des slots de réplication, et ainsi estimer la quantité de données envoyée aux souscripteurs.
Apports de la version 15
- Ajout du support des transactions préparées (
two-phase commit
) à la réplication logique native, et compatibilité avec l’option de streaming également :
CREATE SUBSCRIPTION mysub
CONNECTION 'conninfo'
PUBLICATION mypub
WITH (two-phase = on, streaming = true);
- Ajout de la possibilité de filtrer les colonnes d’une table sur une publication :
CREATE PUBLICATION mypub FOR TABLE sales (order_id, ordered_at);
- Ajout de la possibilité de filtrer des lignes d’une table sur une publication par l’ajout d’une clause
WHERE
:
CREATE PUBLICATION mypub FOR TABLE sensor WHERE (device = `rpi`);
- Ajout de la possibilité de publier toutes les tables d’un schéma à une publication :
CREATE PUBLICATION mypub FOR ALL TABLES IN SCHEMA auditing;
- Ajout de la désactivation automatique d’une souscription sur erreur avec le paramètre
disable_on_error
:
CREATE SUBSCRIPTION mysub
CONNECTION 'conninfo'
PUBLICATION mypub
WITH (disable_on_error = true);
- Ajout de la vue
pg_stat_subscription_stats
fournissant des statistiques sur les erreurs survenues sur des souscriptions.
Apports de la version 16
- Ajout d’un paramètre
origin
sur les souscriptions pour prévenir les boucles de réplication bidirectionnelle :
CREATE SUBSCRIPTION <sub-name> CONNECTION 'conninfo' PUBLICATION <pub-list> [WITH (origin = NONE|ANY)]
Le paramètre origin = NONE
permet de filtrer les transactions n’ayant pas de nœud d’origine, alors que origin = ANY
envoie toutes les transactions ;
-
Ajout du décodage logique depuis un serveur standby. Il est nécessaire de passer le paramètre
wal_level
àlogical
sur le primaire et le standby. Il est possible d’utiliser la vuepg_replication_slots
afin de vérifier si un slot de réplication est invalidé (champsconflicting
) par un conflit avec le primaire. -
Ajout du paramètre
run_as_owner
sur la souscription (par défaut àfalse
). Permet d’exécuter la réplication logique avec les privilèges du propriétaire des tables en lieu et place des privilèges du propriétaire de la souscription ; -
Possibilité d’autoriser les rôles non superuser à créer des souscriptions, en octroyant le rôle
pg_create_subscription
, le privilègeCREATE
sur la base de données et un mot de passe pour l’authentification ; -
Parallélisation de l’application des changements pour les transactions longues via l’utilisation de workers supplémentaires (si disponible) et l’introduction côté souscription d’une nouvelle valeur
parallel
pour le paramètrestreaming
. Un nouveau paramètre,max_parallel_apply_workers_per_subscription
, permet de limiter le nombre deparallel apply worker
(valeur par défaut à 2). Les workers utilisent le pool défini par le paramètremax_logical_replication_workers
(par défaut à 4), qui inclut le worker principal, les workers parallèles et les workers de synchronisation de tables. Le poolmax_logical_replication_workers
est lui même pris dans le pool défini parmax_workers_processes
(par défaut à 8); -
Possibilité pour la réplication logique de copier les tables au format binaire, pendant la phase de synchronisation. Auparavant, même avec le paramètre
binary = true
côté souscription, la synchronisation des tables se faisait au format texte ; -
Possibilité d’utiliser d’autres index que
PRIMARY KEY
etREPLICA IDENTITY
sur les souscriptions pour accélérer les opérationsUPDATE
ouDELETE
. Sans cela, il fallait exécuter un scan séquentiel de la table. Les index utilisables sont les indexbtree
non-partiels avec au moins une colonne référencée. Pour rappel,REPLICA IDENTITY
permet de modifier quelles sont les informations inscrites dans les WAL pour identifier les lignes qui sont mises à jour ou supprimées. Les valeurs possibles sont :DEFAULT
(valeur par défaut pour les tables utilisateurs)USING INDEX index_name
FULL
NOTHING
(valeur par défaut pour les tables systèmes)
Qu’attendre de la version 17
- Migration des slots de réplication avec
pg_upgrade
sur le nouveau cluster ; - Synchronisation des slots de réplication du primaire vers les standbys, afin d’assurer la bascule d’une souscription sur une nouvelle publication (standby promu) lors d’un failover ;
- Réplication des séquences ;
- Réplication des opérations DDL.