Guide pour configurer la réplication primaire-réplica Redis

La réplication Redis est un modèle fondamental pour atteindre une haute disponibilité, une redondance des données et une évolutivité en lecture. En configurant un primaire (anciennement appelé maître) et un ou plusieurs réplicas (anciennement appelés esclaves), vous garantissez que les données écrites sur le primaire sont automatiquement copiées sur tous les réplicas connectés.

Ce guide montre comment configurer la réplication primaire-réplica Redis, vérifier que la synchronisation fonctionne et éviter les erreurs courantes qui exposent Redis ou laissent les réplicas silencieusement obsolètes.

Comprendre les fondamentaux de la réplication Redis

La réplication Redis est asynchrone (ce qui signifie que le primaire n'attend pas que le réplica accuse réception des écritures), permettant des performances élevées. Elle fonctionne principalement en deux phases : la synchronisation initiale et la synchronisation continue.

Synchronisation complète (SYNC)

Lorsqu'un réplica se connecte à un primaire pour la première fois, ou après une interruption réseau qui empêche une resynchronisation partielle, une synchronisation complète se produit :

Le réplica envoie une commande PSYNC au primaire.
Le primaire démarre un processus de sauvegarde en arrière-plan pour générer un fichier d'instantané RDB (.rdb).
Le primaire met en mémoire tampon toutes les nouvelles commandes d'écriture reçues pendant la création du RDB.
Une fois le fichier RDB terminé, le primaire l'envoie au réplica.
Le réplica charge le fichier RDB en mémoire.
Enfin, le primaire envoie toutes les commandes d'écriture mises en mémoire tampon au réplica pour le rattraper.

Resynchronisation partielle (PSYNC)

Redis 2.8+ prend en charge la resynchronisation partielle. Si le lien entre le primaire et le réplica se rompt brièvement, le réplica peut demander uniquement les commandes manquantes depuis la rupture du lien, en utilisant le tampon de backlog de réplication (un tampon circulaire configurable sur le primaire).

Prérequis et configuration

Avant de configurer la réplication, assurez-vous d'avoir au moins deux instances Redis distinctes en cours d'exécution (ou des configurations distinctes sur des ports différents sur le même serveur pour les tests).

Pour ce guide, nous supposons la configuration suivante :

Instance	Rôle	Adresse IP	Port	Fichier de configuration
Primaire	Primaire	192.168.1.100	6379	`redis-primary.conf`
Réplica 1	Réplica	192.168.1.101	6380	`redis-replica-1.conf`

Étape 2.1 : Configurer l'instance primaire

Assurez-vous que votre instance primaire est prête à accepter les connexions des réplicas et configurée pour gérer la persistance (RDB ou AOF) si nécessaire pour la stabilité du primaire lui-même.

Paramètres cruciaux du primaire :

Liaison : Assurez-vous que le primaire est lié à une adresse IP publique ou à 0.0.0.0 s'il fonctionne sur plusieurs machines. Si vous utilisez des pare-feu, assurez-vous que le port 6379 est ouvert pour les adresses IP des réplicas.
Persistance : Bien que non strictement requise pour la réplication elle-même, l'activation de RDB/AOF est fortement recommandée pour la persistance des données du primaire.

# redis-primary.conf
port 6379
bind 0.0.0.0 # Se lie à toutes les interfaces (nécessaire pour les réplicas externes)
# Activer la persistance RDB
save 900 1
save 300 10
save 60 10000

Étape 2.2 : Configurer l'instance réplica

Le cœur de la configuration d'un réplica réside dans la directive replicaof. Elle indique à l'instance avec quel primaire elle doit synchroniser ses données.

Paramètres cruciaux du réplica :

Port : Utilisez un port différent si vous exécutez sur la même machine.
Directive de réplication : Utilisez replicaof ou slaveof (l'ancien nom).

# redis-replica-1.conf
port 6380

# *** Configuration essentielle de la réplication ***
replicaof 192.168.1.100 6379

# Assurer que les réplicas sont en lecture seule (par défaut depuis Redis 5)
replica-read-only yes

# Recommander de désactiver la persistance sur les réplicas si la HA est gérée par Sentinel/Cluster
# Si la persistance est nécessaire pour des redémarrages rapides, laissez-la activée.
save ""

Remarque : Si le primaire nécessite un mot de passe, configurez le réplica avec masterauth <mot_de_passe>. Dans Redis 6 et les configurations ACL ultérieures, configurez également masteruser lorsque l'utilisateur de réplication n'est pas l'utilisateur par défaut.

Méthodes de mise en œuvre

Vous pouvez implémenter la réplication en modifiant le fichier de configuration et en redémarrant le serveur, ou dynamiquement en exécutant la commande REPLICAOF depuis redis-cli.

Méthode 3.1 : Fichier de configuration (recommandé pour la production)

Après avoir mis à jour redis-replica-1.conf comme indiqué ci-dessus, démarrez les deux instances :

# Démarrer le primaire
redis-server redis-primary.conf

# Démarrer le réplica 1
redis-server redis-replica-1.conf

Au démarrage, le réplica 1 tentera immédiatement de se connecter au primaire à 192.168.1.100:6379 et commencera le processus de synchronisation.

Méthode 3.2 : Configuration dynamique

Si une instance Redis est déjà en cours d'exécution et que vous souhaitez la convertir en réplica sans redémarrage, exécutez REPLICAOF via redis-cli.

Connectez-vous à l'instance que vous souhaitez convertir en réplica (fonctionnant sur le port 6380 dans notre exemple) :
```
redis-cli -p 6380
```

Exécutez la commande de réplication :

127.0.0.1:6380> replicaof 192.168.1.100 6379
OK

L'instance sur le port 6380 supprimera toutes les données précédentes et initiera une synchronisation complète (SYNC) avec le nouveau primaire.

⚠️ Avertissement : Désactivation de la réplication

Pour transformer un réplica en instance primaire autonome, exécutez replicaof no one sur cette instance.

4. Surveillance de l'état de la réplication

La surveillance de l'état de la connexion est essentielle pour garantir la cohérence des données. Utilisez la commande INFO replication via redis-cli sur le primaire et le réplica.

4.1 Vérification de l'état du primaire

Connectez-vous au primaire (6379) et vérifiez combien de réplicas sont connectés et leur état :

redis-cli -p 6379 INFO replication

Extrait de sortie attendu (Primaire) :

# Replication
role:master
connected_slaves:1
slave0:ip=192.168.1.101,port=6380,state=online,offset=2048,lag=0
master_replid:a9b1c2...
master_replid2:000000...
master_repl_offset:2048

role:master confirme son rôle.
connected_slaves:1 confirme que le réplica est vu.
state=online est l'état stable souhaité.
lag=0 ou une valeur faible signifie que le réplica répond rapidement. La réplication Redis reste asynchrone, donc ce n'est pas une garantie de zéro perte de données.

4.2 Vérification de l'état du réplica

Connectez-vous au réplica (6380) et vérifiez l'état du lien avec le primaire :

redis-cli -p 6380 INFO replication

Extrait de sortie attendu (Réplica) :

# Replication
role:slave
master_host:192.168.1.100
master_port:6379
master_link_status:up
master_sync_in_progress:0
slave_priority:100
slave_read_only:1

role:slave confirme son rôle.
master_link_status:up confirme que la connexion est active et saine.
master_sync_in_progress:0 signifie que la synchronisation initiale est terminée.

Meilleures pratiques et optimisation de la réplication

5.1 Mode lecture seule du réplica

Par défaut, les réplicas sont en lecture seule (replica-read-only yes). C'est un mécanisme de sécurité critique. Tenter d'écrire sur un réplica entraînera une erreur, garantissant la cohérence des données dans le cluster.

Si vous désactivez le mode lecture seule, toute écriture sur le réplica sera locale et sera écrasée si le lien de réplication se rompt et qu'une synchronisation complète se produit.

5.2 Optimisation du temps de synchronisation

Si votre ensemble de données est très volumineux, le processus SYNC initial peut être lent. Tenez compte de ces facteurs :

Bande passante réseau : Assurez-vous d'une bande passante suffisante entre le primaire et les réplicas pour le transfert RDB.
Génération RDB : Le primaire a besoin de CPU et d'E/S disque pour générer le fichier RDB. Assurez-vous que le serveur dispose de ressources disponibles pendant la synchronisation.
Désactiver la persistance disque sur les réplicas (optionnel) : Si le primaire gère toute la persistance et que le réplica est uniquement pour l'évolutivité en lecture, définir save "" sur le réplica évite la surcharge d'E/S liée à l'écriture des fichiers RDB, accélérant les redémarrages.

5.3 Sécurité et configuration réseau

Il est crucial que le primaire n'expose pas publiquement son port de réplication (6379 ou autre) sur Internet. Configurez des règles de pare-feu pour autoriser le trafic de réplication uniquement depuis les adresses IP désignées des serveurs réplicas.

5.4 Utiliser les réplicas pour l'évolutivité en lecture

Le principal avantage de la réplication est la distribution de la charge de lecture. Dirigez les applications qui effectuent principalement des opérations de lecture vers les instances réplicas, réservant le primaire pour les opérations d'écriture, améliorant ainsi le débit global du système.

Prochaines étapes

La configuration de la réplication primaire-réplica Redis est essentielle pour créer des applications résilientes et hautes performances. En configurant correctement la directive replicaof et en surveillant régulièrement l'état du lien à l'aide de INFO replication, vous créez une base pour une haute disponibilité et une évolutivité en lecture efficace.

Bien que ce guide se concentre sur la configuration de base, les environnements de production intègrent souvent des couches supplémentaires d'automatisation, telles que Redis Sentinel pour la promotion automatique du primaire et la détection des pannes, ou Redis Cluster pour le partitionnement et la distribution automatiques des données sur plusieurs nœuds.