Redis / Valkey : exploitation courante et scénarios de panne (Cluster et Sentinel)

Ce n'est pas une installation : runbook par scénario pour administrer au quotidien un Redis Cluster existant ou une architecture master/replica avec Sentinel, et la remettre en état en cas de panne (Redis 7.2, Redis 8 et Valkey). Cluster : contrôle de santé, ajout/retrait de nœuds, rebalance/reshard, failover manuel (différence entre FORCE et TAKEOVER), remplacement d'un nœud en panne et --cluster fix. Sentinel : état et quorum, SENTINEL FAILOVER, ajout/retrait de nœuds et SENTINEL RESET, modification des paramètres. Pour les deux : diagnostic de la pression mémoire et des clés volumineuses/très sollicitées. Si vous ne savez pas quoi faire, commencez par le contrôle de santé ; la restauration depuis une sauvegarde et le durcissement de la sécurité font l'objet de guides Redis distincts.

Topologie: Redis Cluster (3+ masters + replicas) ou Sentinel (1 master + replicas + 3 Sentinel)

Scénarios

• Contrôle de santé du cluster (--cluster check, CLUSTER INFO / NODES) — Lecture seule : tous les slots sont-ils couverts, les nœuds sont-ils d'accord sur la configuration, y a-t-il un nœud tombé (fail) ou un master sans replica. Commencez ici si vous ne savez pas quoi faire.
• Ajouter un nœud au cluster (master ou replica) — Une nouvelle instance (cluster-enabled yes, vide) est prête : elle rejoint le cluster comme master et reçoit des slots, ou devient la replica d'un master. Aucune interruption.
• Retirer un nœud du cluster (vider ses slots + del-node) — Un master ou une replica est mis hors service : les slots du master sont déplacés vers les autres masters, puis le nœud est retiré du cluster. Aucune interruption ; des redirections ASK ont lieu pendant la migration.
• Redistribuer les slots (rebalance / reshard) — Les slots ou la mémoire sont déséquilibrés entre les masters, un nouveau master n'a reçu aucun slot, ou un nombre donné de slots doit être déplacé d'un master vers un autre.
• Failover manuel : promouvoir une replica en master (CLUSTER FAILOVER, FORCE, TAKEOVER) — Une maintenance est prévue sur le serveur du master (planifiée, sans perte de données), ou le master est injoignable et aucun failover automatique n'a eu lieu (FORCE / TAKEOVER ; risque de perte de données).
• Remplacer un master / nœud en panne (FORGET, nouvelle replica, --cluster fix) — Le serveur d'un nœud est définitivement perdu : si sa replica est devenue master, l'ancien nœud est oublié et une nouvelle replica est ajoutée à sa place ; s'il n'avait pas de replica, ses slots restent sans propriétaire et sont refermés avec --cluster fix (les données de ces slots sont perdues).
• État de Sentinel : master, replicas, Sentinel, quorum — Lecture seule : l'adresse du master vue par les Sentinel, les replicas, les autres Sentinel, CKQUORUM et les derniers événements de failover. Commencez ici si vous ne savez pas quoi faire dans une architecture Sentinel.
• Failover manuel avec Sentinel (SENTINEL FAILOVER) — Une maintenance est prévue sur le serveur du master : Sentinel promeut la replica la plus adaptée en master et redirige les autres replicas et les clients vers le nouveau master. Interruption de 1 à 2 s ; aucune perte de données tant que le master tourne.
• Ajouter / retirer / remplacer un nœud dans une architecture Sentinel (SENTINEL RESET) — Une replica ou un Sentinel a été retiré définitivement ou vient d'être ajouté : la nouvelle replica se connecte avec REPLICAOF, et les entrées obsolètes des Sentinel sont nettoyées avec SENTINEL RESET.
• Modifier le quorum et les paramètres de Sentinel (SENTINEL SET) — Le nombre de Sentinel a changé, ou le failover se déclenche trop tard/trop tôt : quorum, down-after-milliseconds, failover-timeout et parallel-syncs sont modifiés sur tous les Sentinel.
• Pression mémoire : diagnostic de l'utilisation, de la fragmentation et de l'eviction — used_memory approche de maxmemory, erreurs 'OOM command not allowed', l'eviction augmente, la RSS est plus grande que prévu, ou les buffers de replica/AOF ont gonflé. Le diagnostic est en lecture seule ; les solutions sont décrites à part.
• Trouver les clés volumineuses et très sollicitées (--bigkeys, --memkeys, --hotkeys) — La mémoire ou le CPU d'un nœud est plus élevé que celui des autres, il y a des pics de latence, DEL est long : les clés les plus volumineuses et les plus sollicitées sont identifiées puis nettoyées sans risque (UNLINK).

Avant de commencer

• … est installé sur le serveur d'administration (il est fourni avec …, /usr/bin/…) et peut joindre …l'instance ……tous les nœuds du cluster, sur le port client et sur le port du cluster bus (port + 10000)…les Sentinel (…) et Redis (…)….
• Vous disposez du mot de passe … (requirepass / masterauth) ; il est demandé dans les étapes ou lu dans la variable d'environnement REDIS_PASS. Si vous utilisez des ACL, l'utilisateur doit avoir +@admin (commandes cluster/sentinel) et +@keyspace.
• Une demande de changement est ouverte et l'équipe applicative est informée. Un failover ou une migration de slots peut provoquer de brèves redirections MOVED/ASK ou des coupures de connexion côté clients ; les clients compatibles cluster (cluster-aware) les suivent d'eux-mêmes.
• La nouvelle instance … est prête comme dans le guide d'installation Redis Cluster : même version de …, cluster-enabled yes, mêmes requirepass/masterauth, répertoire de données vide (pas d'ancien nodes-.conf, ni RDB/AOF), port client et port bus (port + 10000) ouverts dans le firewall.

Phases du guide

• État : couverture des slots, nœuds et cohérence de la configuration (lecture seule) — Contrôler le cluster (--cluster check) · Afficher les nœuds, les rôles et la répartition des replicas · Interpréter le résultat
• 1. Diagnostic : le nouveau nœud est-il vide et joignable ? — Vérifier le nouveau nœud et le cluster
• 2. Application : ajouter le nœud — Ajouter le nœud au cluster (--cluster add-node) · Répartir des slots sur le nouveau master (rebalance) · Prévoir une replica pour le nouveau master
• 3. Vérification — Vérifier le cluster et le nouveau nœud
• 1. Diagnostic : le nœud est-il un master, a-t-il des slots ? — Afficher le rôle et les slots du nœud à retirer
• 2. Application : vider les slots et retirer le nœud — Déplacer les slots du master vers les autres masters · Retirer le nœud du cluster (--cluster del-node) · Désactiver le service sur le serveur retiré
• 3. Vérification — Vérifier le cluster
• 1. Diagnostic : répartition actuelle — Slots, clés et mémoire par master
• 2. Application — …Équilibrer les slots (rebalance)…Déplacer … slots (reshard)…
• 1. Diagnostic — Afficher le rôle de la replica et son lien avec le master
• 2. Application — Lancer le failover (CLUSTER FAILOVER… FORCE… TAKEOVER…)
• 3. Vérification — Vérifier la nouvelle organisation
• 1. Diagnostic : nœud perdu et couverture des slots — Afficher les nœuds en état fail et les slots sans propriétaire
• 2. Application : oublier le nœud perdu — Faire oublier le nœud perdu par tous les nœuds (CLUSTER FORGET) · Refermer les slots sans propriétaire (--cluster fix) · Ajouter le nouveau nœud comme replica
• 3. Vérification et suite — Vérifier le cluster
• État : master, replicas, Sentinel (lecture seule) — Le master et le quorum vus par Sentinel · Lister les replicas et les autres Sentinel · Rechercher les derniers événements de failover dans le log de Sentinel
• 1. Diagnostic — Vérifier que le quorum et les replicas sont prêts
• 2. Application — Lancer le failover (SENTINEL FAILOVER)
• 3. Vérification — Vérifier le nouveau master et les replicas
• 1. Diagnostic — Nombre de replicas et de Sentinel connus des Sentinel
• 2. Application — Rattacher la nouvelle replica au master · Arrêter le service de la replica retirée · Démarrer le nouveau Sentinel · Arrêter le Sentinel retiré · SENTINEL RESET sur tous les Sentinel
• 3. Vérification — Revérifier les nombres et le quorum
• 1. Diagnostic — Afficher les paramètres actuels sur chaque Sentinel
• 2. Application — Passer … à … sur tous les Sentinel
• 1. Diagnostic : mémoire, limite et eviction — Afficher l'utilisation mémoire et la limite (INFO memory) · MEMORY DOCTOR et MEMORY STATS · Afficher les paramètres mémoire
• 2. Solutions — Solution selon la situation
• 1. Diagnostic : clés volumineuses et très sollicitées — Plus grosses clés par type (--bigkeys) · Plus grosses clés en mémoire (--memkeys) · Clés très sollicitées (--hotkeys) · Examiner la taille et le type d'une clé
• 2. Solution — Supprimer sans risque la clé volumineuse (UNLINK)