Guide de configuration de la réplication maître-réplique Redis.

Guide de configuration de la réplication Primaire-Réplique Redis

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

Ce guide fournit un tutoriel complet, étape par étape, pour configurer la réplication Primaire-Réplique Redis. Nous couvrirons les directives de configuration essentielles, les méthodes de configuration dynamique et les étapes de surveillance critiques nécessaires pour construire un déploiement Redis robuste et fiable.

1. Comprendre les fondamentaux de la réplication Redis

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

Synchronisation complète (SYNC)

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

La réplique envoie une commande PSYNC au primaire.
Le primaire lance un processus de sauvegarde en arrière-plan pour générer un fichier de snapshot 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 à la réplique.
La réplique charge le fichier RDB en mémoire.
Enfin, le primaire envoie toutes les commandes d'écriture mises en mémoire tampon à la réplique pour qu'elle rattrape son retard.

Resynchronisation partielle (PSYNC)

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

2. 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 fonctionnant 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éplique 1	Réplique	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épliques et qu'elle est configurée pour gérer la persistance (RDB ou AOF) si nécessaire pour la stabilité du primaire.

Paramètres cruciaux du primaire :

Liaison (Binding) : 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-feux, assurez-vous que le port 6379 est ouvert pour les adresses IP des répliques.
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 # Lie à toutes les interfaces (nécessaire pour les répliques externes)
# Activer la persistance RDB
save 900 1
save 300 10
save 60 10000

Étape 2.2 : Configurer l'instance réplique

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

Paramètres cruciaux de la réplique :

Port : Utilisez un port différent si vous l'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

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

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

Note : Si le primaire est sécurisé par un mot de passe (en utilisant requirepass), la réplique doit être configurée avec masterauth <mot_de_passe> pour s'authentifier correctement.

3. Méthodes d'implémentation

Vous pouvez implémenter la configuration de réplication soit en modifiant le fichier de configuration (redis.conf) et en redémarrant le serveur, soit dynamiquement en utilisant la commande CONFIG SET.

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 la réplique 1
redis-server redis-replica-1.conf

Au démarrage, la réplique 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 configurer comme réplique sans redémarrage, utilisez CONFIG SET via redis-cli.

Connectez-vous à l'instance que vous souhaitez convertir en réplique (en cours d'exécution sur le port 6380 dans notre exemple) :

bash redis-cli -p 6380
Exécutez la commande de réplication :

bash 127.0.0.1:6380> replicaof 192.168.1.100 6379 OK

L'instance sur le port 6380 abandonnera toute donnée précédente et initiera une synchronisation complète (SYNC) avec le nouveau primaire.

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

Pour reconvertir une réplique en instance primaire autonome, exécutez replicaof no one sur cette instance.

4. Surveillance du statut 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 la réplique.

4.1 Vérification du statut du primaire

Connectez-vous au primaire (6379) et vérifiez combien de répliques sont connectées 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 la réplique est vue.
state=online est l'état stable souhaité.
lag=0 (ou un très petit nombre) indique une performance de transfert de données synchrone réussie.

4.2 Vérification du statut de la réplique

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

redis-cli -p 6380 INFO replication

Extrait de sortie attendu (Réplique) :

# 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.

5. Bonnes pratiques et optimisation de la réplication

5.1 Mode lecture seule des répliques

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

Si vous désactivez le mode lecture seule, toutes les écritures sur la réplique seront locales et seront écrasées si le lien de réplication se brise 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. Prenez en compte les facteurs suivants :

Bande passante réseau : Assurez une bande passante suffisante entre le primaire et les répliques 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épliques (Optionnel) : Si le primaire gère toute la persistance et que la réplique sert uniquement à la mise à l'échelle en lecture, définir save "" sur la réplique évite la surcharge d'E/S de l'écriture des fichiers RDB, accélérant ainsi 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) à Internet. Configurez des règles de pare-feu pour autoriser le trafic de réplication uniquement à partir des adresses IP désignées des serveurs répliques.

5.4 Utiliser les répliques pour la mise à l'échelle 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épliques, en réservant le primaire pour les opérations d'écriture, améliorant ainsi le débit global du système.

Conclusion

La configuration de la réplication Primaire-Réplique Redis est essentielle pour construire des applications résilientes et performantes. 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 la haute disponibilité et une mise à l'échelle efficace en lecture.

Bien que ce guide se concentre sur la configuration de base, les environnements de production intègrent souvent des couches d'automatisation supplémentaires, 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.