UNIVERSITÉ DE N’DJAMENA
FACULTÉ DES SCIENCES EXACTES ET APPLIQUEES
DÉPARTEMENT DE L’INFORMATIQUE
MASTER INGENIERIE DE DONNEES
MASTER 1
BASE DE DONNEES AVANCEE
LA
REPLICATION
LOGIQUE
Sous PostgreSQL
Réalisé et présenté par : Chargé de cours :
1. DINGAMMADJI NARSEM JOSUE
Dr BATOUMA NARKOY
2. MANGKOUNDJAL KORNA RAISSA
3. MOUSSA RIDWANE
PLAN DU TRAVAIL
I- Introduction
II- Principe de réplication logique
III- Mise en place
IV- Conclusion
REPLICATION LOGIQUE 1
I. INTRODUCTION
La réplication logique dans PostgreSQL permet de synchroniser des données entre
deux ou plusieurs instances sans copier toute la base de données. Elle se distingue
de la réplication physique par sa capacité à répliquer uniquement certaines tables
ou certaines colonnes de la table.
La réplication physique copie les blocs de données de toute l'instance tandis que
la réplication logique réplique des modifications spécifiques au niveau des tables.
II. PRINCIPE DE LA REPLICATION LOGIQUE
La réplication logique repose sur les flux de modifications des données (par
exemple, les insertions, mises à jour, suppressions) capturées et envoyées à un ou
plusieurs réplicas.
Cette technique repose sur deux concepts fondamentaux :
Publication : Une publication est un ensemble de modifications (INSERT,
UPDATE, DELETE) d’une ou plusieurs tables que le serveur source met à
disposition. Une publication peut inclure toutes les tables de la base ou
uniquement un sous-ensemble de tables spécifiques. Elle se crée ainsi :
CREATE PUBLICATION nom_publication FOR ALL TABLES;
On peut également créer une publication limitée à certaines tables :
CREATE PUBLICATION nom_publication FOR TABLE table1, table2;
Abonnement : Un abonnement permet à un serveur cible de recevoir les
modifications publiées par un serveur source. Lorsque le serveur cible crée une
souscription à une publication, il commence par synchroniser les données initiales
des tables concernées, puis applique en continu les modifications futures envoyées
par le serveur source.
CREATE SUBSCRIPTION nom_subscription
CONNECTION 'host=adresse_ip port=5432 dbname=ma_base user=replicator
password=secret'
PUBLICATION nom_publication;
REPLICATION LOGIQUE 2
Les points importants de l’abonnement :
La connexion entre le serveur source et le serveur cible doit être configurée
correctement via pg_hba.conf.
Une souscription crée un slot de réplication sur le serveur source, qui
permet de conserver un historique des modifications à envoyer.
Les données sont transmises au fil de l’eau, soit de manière synchrone, soit
asynchrone selon la configuration.
En d’autres termes, le serveur source joue le rôle d’éditeur, tandis que le serveur
cible est un abonné qui reçoit les mises à jour des données.
Figure1 : Illustration de la réplication
1. Serveur Source (instance 1) : crée et maintient une publication des
modifications appliquées aux tables.
2. Slot de réplication : garantit que les journaux de transactions (WAL)
contenant les modifications restent disponibles jusqu'à ce que le serveur
cible les consomme.
3. Serveur Cible (instance 2) : s’abonne à la publication et applique les
modifications en temps réel.
Dans le cadre de la réplication logique, on ne réplique pas une instance vers une
autre. On publie les modifications effectuées sur le contenu d’une table à partir
d’un serveur. Ce serveur est le serveur origine, ou publieur (publisher). Sur ce
serveur, on crée des « publications ». Une publication enregistre un jeu de
modifications que d’autres serveurs pourront récupérer en s’abonnant
(subscription). De ceci, il découle que : – le serveur origine est le serveur où les
écritures sur une table sont enregistrées pour publication vers d’autres serveurs ;
REPLICATION LOGIQUE 3
– les serveurs intéressés par ces enregistrements sont les serveurs destinations ; –
un serveur origine doit proposer une publication des modifications ; – les serveurs
destinations intéressés doivent s’abonner à une publication.
III. MISE EN PLACE
Nous allons voir les étapes de configuration dans le cas simple d’une publication
origine alimentant un abonnement destination
Configurer le serveur origine : utilisateur de réplication
CREATE ROLE logrepli LOGIN REPLICATION ;
GRANT SELECT ON ALL TABLES IN SCHEMA monschema TO logrepli ;
# pg_hba.conf host base_publication logrepli [Link]/XX scram-
sha-25
Pour la réplication logique, il est nécessaire de disposer d’un utilisateur
PostgreSQL capable de se connecter au serveur origine et capable d’initier une
connexion de réplication. Voici la commande pour créer ce rôle :
CREATE ROLE logrepli LOGIN REPLICATION
Cet utilisateur doit pouvoir lire le contenu des tables répliquées. Il lui faut donc le
droit SELECT sur ces objets, souvent simplement ceci :
GRANT SELECT ON ALL TABLES IN SCHEMA public TO logrepli;
Enfin, la connexion du serveur destination doit être possible sur le serveur origine.
Il est donc nécessaire d’avoir une ligne du style :
host base_publication logrepli [Link]/XX scram-sha-256 en
remplaçant [Link]/XX par l’adresse CIDR du serveur destination.
REPLICATION LOGIQUE 4
Configurer le serveur origine : [Link]
– wal_level = logical
– rédémarrage
– logical_decoding_work_mem = 64MB
Configuration du serveur destination
Sur le serveur destination, il n’y a pas de configuration à réaliser dans les fichiers
[Link] et pg_hba.conf .
Ensuite, il faut récupérer la définition des objets répliqués pour les créer sur le
serveur de destination. Un moyen simple est d’utiliser pg_dump et d’envoyer le
résultat directement à psql pour restaurer immédiatement les objets. Cela se fait
ainsi :
pg_dump -h origine --schema-only base | psql base
Créer une publication
CREATE PUBLICATION pub_t1 FOR TABLE t1 ;
CREATE PUBLICATION pub_t1part FOR TABLE t1 (c1, c3); -- v15
CREATE PUBLICATION pub_tout FOR ALL TABLES ;
CREATE PUBLICATION pub_public FOR TABLES IN SCHEMA public ; -- v15
CREATE PUBLICATION pub_filtree FOR TABLE employes WHERE ( ville =
'Brest' ) ; --v15
… WITH ( publish = 'update, delete, insert, truncate') – défaut
WITH (publish_via_partition_root = false) -- défaut, v13
À partir de la version 15, la clause FOR TABLES IN SCHEMA permet de répliquer
toutes les tables du schéma indiqué sans avoir à nommer les tables
spécifiquement. De plus, toute nouvelle table de ce schéma sera répliquée
automatiquement dès sa création. (Il faudra tout de même rafraîchir l’abonnement
sur le destinataire).
REPLICATION LOGIQUE 5
Depuis la version 15, il est possible de ne répliquer que certaines colonnes d’une
table, par exemple ainsi :
CREATE PUBLICATION pub1 FOR TABLE t1 (c1, c3);
Toujours depuis cette version, il est possible de ne répliquer que les lignes validant
une certaine expression. Par exemple :
CREATE PUBLICATION pub_brest FOR TABLE employes WHERE (ville='Brest')
Souscrire à une publication
CREATE SUBSCRIPTION mon_abonnement
CONNECTION 'host=source_host dbname=source_db user=replication_user
password=replication_password'
PUBLICATION ma_publication;
Où :
source_host est l'adresse IP du serveur source.
source_db est la base de données sur le serveur source.
replication_user est l'utilisateur ayant les droits nécessaires pour la
réplication.
ma_publication est le nom de la publication configurée sur le serveur
source.
Avantages :
1. Flexibilité : Permet de répliquer des données spécifiques (tables, colonnes).
2. Réduction de la bande passante : Seulement les changements sont
répliqués.
3. Optimisation de la performance : Idéale pour des environnements
hétérogènes.
4. Mise à l'échelle facile : Facilite l'ajout de nœuds sans répliquer toute la base.
5. Synchronisation en temps réel : Permet une mise à jour rapide des données.
6. Compatibilité avec des bases hétérogènes : Compatible avec différentes
technologies de bases de données.
Limitations :
1. Complexité : Gestion et mise en place plus complexes.
REPLICATION LOGIQUE 6
2. Latence : Peut introduire une certaine latence dans la synchronisation des
données.
3. Consommation de ressources : Processus logiques gourmands en
ressources.
4. Cohérence des données : Difficulté à maintenir la cohérence dans des
systèmes distribués.
5. Dépendance à la source de données : Les changements de schéma peuvent
affecter la réplication.
6. Gestion des conflits : Les conflits de mise à jour peuvent être difficiles à
résoudre.
En résumé, la réplication logique est flexible et efficace, mais elle nécessite une
gestion rigoureuse pour garantir la performance et la cohérence.
IV- CONCLUSION
La réplication logique sous PostgreSQL offre une grande flexibilité pour répliquer
uniquement les données nécessaires, ce qui en fait un choix adapté pour des
architectures distribuées et des applications nécessitant un contrôle fin des
données. Bien qu’elle présente des défis en termes de performance et de gestion,
ses avantages en font un outil puissant pour les administrateurs de bases de
données dans des environnements complexes.
REPLICATION LOGIQUE 7
