Guide Redis Sentinel : Haute Disponibilité et Basculement Automatique

23 mars 2026

12 min de lecture

Récent

TL;DR — Résumé Rapide

Déployez Redis Sentinel pour le basculement automatique et la haute disponibilité. Configurez le quorum, la topologie master-réplique et la sécurité.

Redis Sentinel est la solution de haute disponibilité intégrée à Redis, offrant un basculement automatique, la surveillance de la topologie et la découverte de services sans la complexité de Redis Cluster. Ce guide couvre l’architecture complète, un déploiement à trois nœuds prêt pour la production, la configuration des clients compatibles Sentinel, les concepts de quorum et les contrôles de sécurité nécessaires avant la mise en production.

Prérequis

Trois serveurs Linux (physiques ou virtuels) joignables les uns des autres sur les ports 6379 (Redis) et 26379 (Sentinel).
Redis 7.0 ou supérieur installé sur tous les nœuds.
Accès root ou sudo sur chaque serveur.
Familiarité de base avec les fichiers de configuration Redis et redis-cli.

Architecture de Sentinel

Redis Sentinel s’exécute comme un processus séparé aux côtés de vos instances Redis. Chaque Sentinel remplit quatre rôles :

Surveillance : Vérifie la santé du master et des répliques chaque seconde via PING/INFO.
Notification : Publie des alertes sur les canaux +switch-master, +slave et d’autres via pub/sub.
Basculement automatique : Lorsque le quorum est atteint, Sentinel élit un leader, promeut la meilleure réplique et reconfigure les autres.
Fournisseur de configuration : Les clients interrogent Sentinel avec SENTINEL get-master-addr-by-name pour découvrir l’adresse actuelle du master.

Pourquoi Trois Sentinels ?

Un seul Sentinel est un point unique de défaillance. Deux Sentinels peuvent créer une égalité lors du vote. Trois Sentinels avec quorum 2 garantissent :

Un Sentinel peut échouer et le basculement fonctionne encore.
Deux Sentinels quelconques peuvent s’entendre pour promouvoir un nouveau master.
La minorité ne peut pas déclencher une promotion qui provoquerait un split-brain.

Déployez toujours un nombre impair de Sentinels (3, 5 ou 7).

Étape 1 — Configurer le Master Redis

Sur le Serveur 1 (192.168.1.101), éditez /etc/redis/redis.conf :

bind 0.0.0.0
port 6379
protected-mode no

requirepass "MotDePasseRedisForte123"
masterauth "MotDePasseRedisForte123"

# Persistance (AOF recommandé pour les déploiements Sentinel)
appendonly yes
appendfsync everysec

# Protection split-brain : rejette les écritures si aucune réplique n'a synchronisé en 10s
min-replicas-to-write 1
min-replicas-max-lag 10

Démarrez et activez Redis :

sudo systemctl start redis-server
sudo systemctl enable redis-server

Étape 2 — Configurer les Répliques Redis

Sur le Serveur 2 (192.168.1.102) et le Serveur 3 (192.168.1.103), éditez /etc/redis/redis.conf :

bind 0.0.0.0
port 6379
protected-mode no

requirepass "MotDePasseRedisForte123"
masterauth "MotDePasseRedisForte123"

# Pointer vers le master initial
replicaof 192.168.1.101 6379

# Les répliques refusent les commandes d'écriture des clients (sécurisé par défaut)
replica-read-only yes

# Persistance
appendonly yes
appendfsync everysec

# Priorité de promotion de la réplique (plus faible = préféré ; 0 = ne jamais promouvoir)
replica-priority 100

Vérifiez la réplication depuis le master :

redis-cli -a "MotDePasseRedisForte123" INFO replication

Vous devriez voir role:master et deux entrées slave avec state:online.

Étape 3 — Configurer Redis Sentinel

Créez /etc/redis/sentinel.conf sur les trois serveurs :

port 26379
daemonize yes
logfile "/var/log/redis/sentinel.log"
dir /var/lib/redis

# Surveiller le master nommé "mymaster" avec quorum 2
sentinel monitor mymaster 192.168.1.101 6379 2

# Mot de passe pour s'authentifier auprès du master (et des répliques après le basculement)
sentinel auth-pass mymaster MotDePasseRedisForte123

# Marquer le master comme SDOWN après 5 secondes sans réponse
sentinel down-after-milliseconds mymaster 5000

# Délai maximum pour l'ensemble du processus de basculement (ms)
sentinel failover-timeout mymaster 60000

# Une seule réplique se synchronise depuis le nouveau master à la fois
sentinel parallel-syncs mymaster 1

Démarrez Sentinel sur les trois serveurs :

sudo redis-sentinel /etc/redis/sentinel.conf

Vérifiez la découverte de topologie :

redis-cli -p 26379 SENTINEL masters
redis-cli -p 26379 SENTINEL replicas mymaster
redis-cli -p 26379 SENTINEL sentinels mymaster
redis-cli -p 26379 SENTINEL ckquorum mymaster

Le Processus de Basculement Étape par Étape

SDOWN (Subjectivement Hors Service) : Un Sentinel cesse de recevoir PONG du master dans le délai down-after-milliseconds et le marque comme SDOWN.
ODOWN (Objectivement Hors Service) : Le Sentinel diffuse SENTINEL is-master-down-by-addr à ses pairs. Lorsque le nombre de quorum répond positivement, l’état passe à ODOWN.
Élection du leader : Les Sentinels qui s’accordent sur ODOWN votent pour un leader en utilisant l’algorithme de type Raft intégré à Sentinel.
Sélection de la réplique : Le leader classe les répliques selon : le temps de déconnexion du master → replica-priority (plus faible gagne) → le décalage de réplication (plus de données gagne) → l’ID de processus lexicographique.
Promotion : Le leader envoie REPLICAOF NO ONE à la réplique choisie, en faisant le nouveau master.
Reconfiguration : Les autres répliques reçoivent REPLICAOF <nouvel-ip-master> 6379. Les Sentinels mettent à jour leurs fichiers sentinel.conf. Les clients qui interrogent Sentinel reçoivent la nouvelle adresse du master.

L’ensemble du processus se termine généralement en 10–30 secondes avec les paramètres par défaut.

Connexion des Clients via Sentinel

Ne codez jamais en dur l’IP du master Redis dans votre application. Utilisez un client compatible Sentinel qui interroge Sentinel pour le master actuel.

Python (redis-py)

from redis.sentinel import Sentinel

sentinel = Sentinel(
    [
        ("192.168.1.101", 26379),
        ("192.168.1.102", 26379),
        ("192.168.1.103", 26379),
    ],
    socket_timeout=0.5,
    password="MotDePasseRedisForte123",
)

master = sentinel.master_for("mymaster", socket_timeout=0.5)
replica = sentinel.slave_for("mymaster", socket_timeout=0.5)

master.set("session:abc", "donnees-utilisateur")
valeur = replica.get("session:abc")

Node.js (ioredis)

const Redis = require("ioredis");

const redis = new Redis({
  sentinels: [
    { host: "192.168.1.101", port: 26379 },
    { host: "192.168.1.102", port: 26379 },
    { host: "192.168.1.103", port: 26379 },
  ],
  name: "mymaster",
  password: "MotDePasseRedisForte123",
  sentinelPassword: "MotDePasseRedisForte123",
});

await redis.set("cle", "valeur");

Sécurité en Production

Protéger Sentinel

Ajoutez requirepass à Sentinel pour que seuls les clients autorisés puissent émettre des commandes Sentinel :

requirepass "MotDePasseAdminSentinel"
sentinel sentinel-pass MotDePasseAdminSentinel

Activer TLS

Redis 6.0+ prend en charge TLS pour les connexions Redis et Sentinel :

tls-port 26380
port 0
tls-cert-file /etc/redis/tls/sentinel.crt
tls-key-file /etc/redis/tls/sentinel.key
tls-ca-cert-file /etc/redis/tls/ca.crt
tls-replication yes

Utiliser les ACL (Redis 6.0+)

# Dans redis.conf
aclfile /etc/redis/users.acl

# users.acl
user default off
user sentinel on >SentinelPass ~* &* +@all
user app on >AppPass ~session:* ~cache:* +GET +SET +DEL +EXPIRE

Comparaison : Sentinel vs Alternatives

Fonctionnalité	Sentinel	Redis Cluster	KeyDB	Dragonfly	Redis Géré
Basculement automatique	Oui	Oui	Oui	Oui	Oui
Fragmentation des données	Non	Oui	Oui	Non	Variable
Complexité de configuration	Moyenne	Élevée	Faible	Faible	Aucune
Exigence client	Compatible Sentinel	Compatible Cluster	Standard	Standard	Standard
Taille max du dataset	RAM d’un nœud	RAM × shards	RAM d’un nœud	RAM d’un nœud	Limité par le plan
Coût	Gratuit	Gratuit	Gratuit	Gratuit	$$/mois
Idéal pour	HA sans fragmentation	Grands datasets	HA drop-in Redis	Haut débit	Sans gestion d’infra

Problèmes Courants et Mises en Garde

Sentinel réécrit son fichier de configuration. Ne modifiez jamais sentinel.conf manuellement pendant l’exécution de Sentinel — Sentinel met continuellement à jour le fichier avec la topologie découverte.

DNS vs adresses IP. Sentinel stocke les adresses du master et des répliques par IP au moment de la découverte. Si vous changez l’IP d’un serveur, Sentinel ne suivra pas les changements DNS.

Lectures obsolètes pendant le basculement. Dans les 10–30 secondes entre la défaillance du master et la promotion de la réplique, les lectures peuvent retourner des données obsolètes. Concevez votre application pour tolérer de brèves lectures obsolètes.

requirepass sans masterauth. Si vous définissez requirepass sur le master mais oubliez masterauth sur les répliques, l’authentification de réplication échoue et les répliques se déconnectent silencieusement.

Résumé

Redis Sentinel fournit la surveillance, le basculement automatique et la découverte de services pour Redis sans nécessiter Cluster.
Déployez au moins 3 instances Sentinel sur des hôtes séparés ; définissez le quorum à 2 pour une configuration à 3 nœuds.
La séquence de basculement progresse de SDOWN → ODOWN → élection du leader → promotion de la réplique → reconfiguration.
Utilisez min-replicas-to-write et min-replicas-max-lag sur le master pour éviter la perte de données par split-brain.
Utilisez toujours un client compatible Sentinel — ne codez jamais l’IP du master en dur.
Sécurisez Sentinel avec requirepass, ACL et TLS dans les environnements de production.

Articles Connexes

Guide & Instructions

Estimated Time: 30m

Tools Needed:

Redis
Redis Sentinel
systemctl

Installer Redis sur les trois nœuds

Installez Redis 7.0 ou supérieur sur le serveur master et sur les deux serveurs répliques. Assurez-vous que les ports 6379 et 26379 sont ouverts entre tous les nœuds dans les règles du pare-feu.

Configurer le master Redis

Éditez /etc/redis/redis.conf sur le nœud master. Définissez bind sur 0.0.0.0, requirepass, masterauth et les options de persistance. Ajoutez min-replicas-to-write 1 et min-replicas-max-lag 10 pour protéger contre le split-brain.

Configurer les répliques Redis

Sur chaque nœud réplique, éditez redis.conf pour ajouter la directive replicaof pointant vers l'IP et le port du master. Configurez replica-read-only yes et utilisez les mêmes valeurs requirepass et masterauth que le master.

Créer et déployer sentinel.conf sur chaque nœud

Créez /etc/redis/sentinel.conf sur chacun des trois serveurs avec sentinel monitor mymaster pointant vers le master, quorum 2, down-after-milliseconds 5000, failover-timeout 60000 et sentinel auth-pass avec le mot de passe du master.

Démarrer Sentinel et vérifier la découverte de topologie

Démarrez Redis Sentinel avec 'sudo redis-sentinel /etc/redis/sentinel.conf' sur tous les nœuds. Exécutez 'redis-cli -p 26379 SENTINEL masters' pour confirmer que les trois Sentinels voient le même master et se sont découverts mutuellement.

Tester le basculement automatique et mettre à jour les clients

Arrêtez le processus master Redis et observez les journaux Sentinel. Confirmez qu'une réplique est promue en quelques secondes. Mettez à jour l'application pour utiliser un client compatible Sentinel pointant vers les trois adresses Sentinel.

Frequently Asked Questions

Comment Redis Sentinel détecte-t-il une défaillance du master ?

Chaque Sentinel envoie un ping au master chaque seconde. Si aucune réponse n'arrive dans le délai down-after-milliseconds, ce Sentinel marque le master comme SDOWN. Lorsque le quorum de Sentinels est d'accord, l'état passe à ODOWN et le basculement commence.

Quel est le nombre minimum d'instances Sentinel requises ?

Il faut au moins 3 instances Sentinel avec un quorum de 2. Un nombre impair évite les égalités lors de l'élection du leader, et la perte d'un Sentinel laisse encore suffisamment d'instances pour atteindre le quorum et déclencher le basculement en toute sécurité.

Redis Sentinel sert-il de proxy pour les connexions clients ?

Non. Sentinel est uniquement une couche de découverte de services. Les clients interrogent Sentinel pour trouver l'adresse du master actuel, puis se connectent directement à Redis. Il est obligatoire d'utiliser une bibliothèque cliente compatible avec Sentinel.

Comment éviter la perte de données par split-brain dans Redis Sentinel ?

Configurez min-replicas-to-write et min-replicas-max-lag sur le master. Le master refusera alors les commandes d'écriture si moins de répliques que requis ont confirmé les données récemment, empêchant un master isolé d'accepter des écritures qui seront perdues après le basculement.

Prérequis

Architecture de Sentinel

Pourquoi Trois Sentinels ?

Étape 1 — Configurer le Master Redis

Étape 2 — Configurer les Répliques Redis

Étape 3 — Configurer Redis Sentinel

Le Processus de Basculement Étape par Étape

Connexion des Clients via Sentinel

Python (redis-py)

Node.js (ioredis)

Sécurité en Production

Protéger Sentinel

Activer TLS

Utiliser les ACL (Redis 6.0+)

Comparaison : Sentinel vs Alternatives

Problèmes Courants et Mises en Garde

Résumé

Articles Connexes

Guide & Instructions

Installer Redis sur les trois nœuds

Configurer le master Redis

Configurer les répliques Redis

Créer et déployer sentinel.conf sur chaque nœud

Démarrer Sentinel et vérifier la découverte de topologie

Tester le basculement automatique et mettre à jour les clients

Frequently Asked Questions

Articles Connexes

Replication MySQL : Configuration Master-Slave pour la Haute Disponibilite

Stratégies de Sauvegarde et Restauration PostgreSQL en Production

Guide d'optimisation VACUUM et autovacuum PostgreSQL