data / redis

Réplication maître-répliquas

Leçon 111 exercice

Explication

Ce que vous allez apprendre

Configurer un répliqua Redis pour qu'il suive un maître
Comprendre le mécanisme interne de synchronisation complète et partielle
Router les lectures vers des répliquas pour soulager le maître
Lire INFO replication pour diagnostiquer l'état d'une réplication
Comprendre pourquoi la réplication seule ne suffit pas à garantir la haute disponibilité

Dans quel contexte ?

Une plateforme e-commerce constate que son unique instance Redis sature en CPU aux heures de pointe, submergée par des milliers de lectures de catalogue produit par seconde en plus des écritures de panier. Plutôt que de sur-dimensionner une seule machine, l'équipe met en place un maître et deux répliquas : les écritures restent sur le maître, mais les lectures de catalogue se répartissent sur les répliquas, divisant la charge par trois sans changer une ligne de logique métier complexe.

D'abord, comment un répliqua rejoint un maître

La commande REPLICAOF <ip> <port> (anciennement SLAVEOF, toujours supportée pour compatibilité) déclare qu'une instance Redis doit désormais suivre un maître. À l'inverse, REPLICAOF NO ONE détache une instance et la fait redevenir un maître autonome — utile lors d'un failover manuel.

Prérequis

Cette leçon suppose que tu maîtrises déjà la persistance RDB et AOF (leçon précédente), car la réplication initiale s'appuie directement sur un snapshot RDB.

Une fois la connexion établie, il faut comprendre ce qui se passe réellement

La synchronisation suit un déroulé précis en quatre étapes : le répliqua se connecte et demande une synchronisation via PSYNC, le maître génère un BGSAVE (un snapshot RDB en arrière-plan) et le transmet, le répliqua charge ce RDB puis reçoit en continu le flux des commandes d'écriture. Si la connexion se coupe brièvement, Redis évite de tout retélécharger : grâce à un backlog de réplication (une fenêtre de commandes récentes gardée en mémoire par le maître), une resynchronisation partielle reprend exactement là où elle s'était arrêtée.

Type de synchronisation	Quand elle se déclenche	Coût
Complète (`full sync`)	Premier attachement, ou backlog dépassé	Élevé : snapshot RDB entier transféré
Partielle (`partial sync`)	Coupure réseau brève	Faible : seules les commandes manquantes sont rejouées

Piège courant

La réplication Redis est asynchrone par défaut : un répliqua peut légèrement retarder par rapport au maître (le replication lag). Router une lecture juste après une écriture critique vers un répliqua peut donc renvoyer une donnée pas encore à jour — un piège classique dans les architectures qui font naïvement du "lire depuis n'importe quel nœud".

Il reste un point essentiel à ne jamais oublier

replica-read-only yes doit rester activé en toute circonstance : il empêche des écritures accidentelles directement sur un répliqua, ce qui créerait une divergence de données silencieuse et très difficile à diagnostiquer ensuite.

Bonne pratique

Surveille systématiquement master_repl_offset côté maître et slave_repl_offset côté répliqua via INFO replication : un écart qui grandit signale un problème réseau ou de charge à corriger avant qu'il ne devienne critique.

Un point mérite d'être clarifié avant d'aller plus loin : la réplication répartit la charge de lecture, mais elle ne bascule pas automatiquement le trafic d'écriture vers un répliqua si le maître tombe. Cette limitation est justement le sujet de la leçon sur le clustering et Sentinel, plus loin dans ce parcours. En attendant, la prochaine leçon change complètement de sujet en explorant comment utiliser Redis comme cache devant une base de données classique.

Commandes & code

Réplication maître-répliquas

# Sur le serveur RÉPLIQUA : se déclarer répliqua d'un maître
REPLICAOF 192.168.1.10 6379          # (ancien nom : SLAVEOF, toujours supporté)

# Repasser en maître autonome (rompt la réplication)
REPLICAOF NO ONE

# Configuration côté répliqua (redis.conf)
replicaof 192.168.1.10 6379
replica-read-only yes                 # empêche les écritures directes sur le répliqua (bonne pratique)
masterauth motdepasse_du_maitre        # si le maître a un mot de passe (requirepass)

# Vérifier l'état de réplication
INFO replication
# role:master / role:slave
# connected_slaves:2
# master_repl_offset:12345          -> position dans le flux de réplication
# slave_repl_offset:12345           -> doit converger vers master_repl_offset

# Forcer une resynchronisation complète (rare, coûteux)
DEBUG SLEEP 0   # (exemple de commande de debug, à ne jamais utiliser en prod sans précaution)

# Fonctionnement interne :
# 1. Le répliqua se connecte au maître et demande une synchronisation complète (PSYNC)
# 2. Le maître fait un BGSAVE et envoie le RDB au répliqua
# 3. Le répliqua charge le RDB, puis reçoit en continu le flux de commandes d'écriture (streaming)
# 4. Si la connexion coupe brièvement, une resynchronisation PARTIELLE reprend là où on s'est arrêté
#    (grâce au backlog de réplication, une fenêtre de commandes récentes gardée en mémoire par le maître)

# Architecture typique : 1 maître (écritures) + N répliquas (lecture, scaling en lecture)
# Exemple d'utilisation applicative : router les lectures vers un répliqua
redis-cli -h replica1.internal -p 6379 GET produit:42     # lecture depuis un répliqua
redis-cli -h master.internal -p 6379 SET produit:42 "..." # écriture toujours vers le maître

Résumé

La réplication Redis est asynchrone par défaut : un répliqua peut être en léger retard (lag) par rapport au maître.
replica-read-only yes évite les incohérences en interdisant les écritures directes sur les répliquas.
La réplication seule n'est PAS de la haute disponibilité automatique : il faut Sentinel ou Cluster pour le failover (voir leçon clustering).

Exercices pratiques

1 disponible

Mission : comprendre pourquoi un client voit un stock obsolète juste après un achat

Objectif : Diagnostiquer un problème de lecture après écriture dû au lag de réplication, et réagir correctement lors d'une coupure réseau brève entre maître et répliqua.

Contexte

Une plateforme e-commerce route toutes les lectures vers des répliquas pour soulager le maître, y compris juste après un achat. Un client vient d'acheter le dernier exemplaire d'un produit, mais un second client voit encore ce produit disponible et l'achète aussi. Tu dois diagnostiquer ce problème, puis anticiper le comportement de la réplication lors d'une coupure réseau.

Résoudre l’exercice →