Guide complet de la réplication et haute disponibilité des bases de données — streaming, logique, synchrone/asynchrone, failover automatique, load balancing lecture, et architecture multi-site.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
Guide complet de la réplication et haute disponibilité des bases de données — streaming, logique, synchrone/asynchrone, failover automatique, load balancing lecture, et architecture multi-site.
Compétence Réplication et Haute Disponibilité des Bases de Données
Vue d'ensemble
La réplication crée des copies synchronisées des données pour assurer la tolérance aux pannes (HA), la répartition des lectures (scale-out read), et la récupération après sinistre (DR). Cette compétence couvre toutes les formes de réplication : streaming, logique, synchrone/asynchrone, multi-master, et les architectures DR multi-site.
Quand l'utiliser
Activez cette compétence lorsque l'utilisateur :
Veut configurer un réplica de lecture PostgreSQL/MySQL/MongoDB
A besoin de haute disponibilité (failover automatique)
Doit synchroniser des données entre datacenters
Veut répliquer vers un serveur de reporting sans impacter la production
Configure un cluster de bases de données (Patroni, Galera, MongoDB Replica Set)
Planifie une reprise après sinistre (DRP)
1. Concepts Fondamentaux
1.1 Modes de réplication
Mode
PostgreSQL
MySQL
MongoDB
Redis
Asynchrone
Streaming asynchrone
Réplication async
Réplication async
Redis Replication
Semi-synchrone
synchronous_standby_names
rpl_semi_sync
w: majority
WAIT
Synchrone
Quorum commit (PostgreSQL 16+)
Group Replication
Réplica sets
Redis Cluster (multi-master)
Logique (multi-version)
pgoutput + pglogical
binlog + décodeur
Change Streams
AOF
1.2 Topologies
Asynchrone (simple) :
Primary ──(async)──→ Réplica (lecture seule)
Semi-synchrone (2 data centers) :
Primary ──(sync)──→ Réplica DC1
└─(async)──→ Réplica DC2 (DR)
Multi-master (actif-actif) :
Node A ←──(sync)──→ Node B
Node B ←──(sync)──→ Node C
Cascading (répartition) :
Primary ──→ Replica1 ──→ Replica2 ──→ Replica3
2. Réplication PostgreSQL
2.1 Streaming Replication (asynchrone, WAL)
# postgresql.conf (Primary)
wal_level = replica
max_wal_senders = 10 # nombre max de réplicas
wal_keep_size = 4096 # 4 GB de WAL gardés
hot_standby = on # lectures sur le réplica
# postgresql.conf (Standby)
primary_conninfo = 'host=192.168.1.10 port=5432 user=replicator password=***'
hot_standby = on # permet les lectures
hot_standby_feedback = on # évite les query conflicts
# postgresql.conf (Primary)
synchronous_commit = on
synchronous_standby_names = '1 (standby1)' # 1 réplica synchrone
# Test de commit : attend que standby1 ait écrit le WAL
// Forcer une élection
rs.stepDown(60); // 60 secondes avant de pouvoir être réélu// Suivre les événements
rs.printSecondaryReplicationInfo();
rs.printReplicationInfo();
DC1 (Primary) ──(sync)──→ DC2 (Standby synchrone)
└─(async)──→ DC3 (Standby asynchrone, DR)
pg_rewind pour récupérer un ancien primary après split-brain
# Utiliser un fencing mechanism (STONITH) en cluster# PostgreSQL : standby peut se promouvoir seulement si etcd/consensus le confirme# MySQL : Group Replication avec majorité# MongoDB : réplica set avec nombre impair de membres
Pièges Courants
Réplication synchrone trop lente. À chaque commit, le PRIMARY attend le standby. Si le standby est loin (> 5ms RTT), les écritures ralentissent. Utiliser semi-sync comme compromis.
Pas de monitoring du lag. Un réplica qui prend du retard est inutile. Monitorer : pg_stat_replication.write_lag, Seconds_Behind_Source, rs.status().members[n].optimeDate.
Split-brain après failover. Deux serveurs qui se croient PRIMARY. Solution : quorum (etcd/Patroni, Sentinel, Galera), STONITH, ou un nombre impair de nœuds.
Blind switchover sans test. Tester le failover mensuellement : les bases non testées ne fonctionnent pas le jour J.
Réplication asynchrone sans file d'attente. Le WAL peut saturer si le réplica est trop lent. Configurer max_wal_size et wal_keep_size généreusement.
Faire confiance à l'auto-failover sans test. Tester : pkill -9 postgres sur le primary, et vérifier que le standby prend le relais en < 30s.
Checklist
Au moins un réplica synchrone ou semi-synchrone configuré
Patroni/Sentinel/Galera/Group Replication installé et testé
Failover testé et documenté (temps de bascule < RTO cible)
Monitoring du lag de réplication en place
Nombre impair de nœuds MongoDB (évite split-brain)