Mise à niveau et migration de Redis : guides pratiques pour les déploiements autonomes, Sentinel et Cluster

Intro

La mise à niveau ou la migration de Redis doit améliorer la sécurité, la stabilité et les performances sans perturber vos applications. Le risque ne réside pas dans la nouvelle version elle-même, mais dans le changement non planifié. Ce guide montre comment planifier et exécuter des mises à niveau Redis avec un risque minimal, vérifier chaque étape et effectuer un retour arrière (rollback) en toute sécurité si nécessaire. Vous ferez l'inventaire de votre environnement, choisirez une voie sûre, parcourrez des exemples concrets pour les topologies autonomes (standalone), Sentinel et Cluster, et terminerez avec les diagnostics, les modes de défaillance et une liste de contrôle reproductible.

Inventaire des versions et de l'environnement

Une mise à niveau solide commence par des faits clairs. Capturez ces éléments avant de toucher à la production.

Prérequis et accès

Accès shell aux hôtes Redis
Capacité de mettre à jour la configuration et de redémarrer Redis sous une fenêtre de maintenance si nécessaire
Accès au DNS ou à la découverte de service pour le basculement des clients
Espace disque suffisant pour une capture instantanée complète supplémentaire (prévoyez au moins 1,5 fois la taille du jeu de données d'espace libre)

Commandes d'inventaire (à exécuter sur chaque nœud)

Identifier la version du binaire :

redis-server -v

Détails du serveur (build, chemin du fichier de configuration) :

redis-cli INFO server

Mode de persistance et planification des instantanés :

redis-cli CONFIG GET appendonly
redis-cli CONFIG GET save

Taille du jeu de données et keyspace :

redis-cli INFO memory
redis-cli INFO keyspace

Réplication et rôle :

redis-cli INFO replication
redis-cli ROLE

Mix de commandes et débit :

redis-cli INFO commandstats
redis-cli INFO stats

Classification de la topologie

Autonome (standalone) : un primaire, éventuellement des réplicas
Sentinel : primaires et réplicas gérés par Sentinel pour la haute disponibilité
Cluster : déploiement shardé avec des masters et des réplicas

Considérations applicatives

Bibliothèques clientes et chaînes de connexion (authentification, TLS, délais d'attente, politiques de nouvelle tentative)
Politique d'éviction des clés et limites de mémoire (CONFIG GET maxmemory, maxmemory-policy)
Temps d'arrêt autorisé et stratégie de basculement (commutation DNS, réutilisation de connexion ou basculement orchestré)

Sauvegardes et vérifications d'intégrité

Créer une capture RDB propre :

redis-cli BGSAVE

Vérifier l'existence et l'horodatage dans le répertoire obtenu via CONFIG GET dir.

Si AOF (Append Only File) est activé, le valider hors ligne sur une copie :

redis-check-aof --fix appendonly.aof

Valider le RDB hors ligne sur une copie :

redis-check-rdb dump.rdb

Interrupteurs de sécurité à noter

stop-writes-on-bgsave-error devrait être yes pour la sécurité (CONFIG GET stop-writes-on-bgsave-error)
appendfsync par défaut everysec est un choix équilibré entre durabilité et performance

Chemin de configuration sûr

Choisissez une approche adaptée à votre topologie et à votre tolérance au risque. Les motifs suivants couvrent la plupart des besoins réels.

Motifs de migration

Redémarrage sur place (in-place restart upgrade) : 30 à 120 secondes d'indisponibilité par nœud. Risque le plus élevé (point unique de retour arrière). À utiliser pour de petites instances autonomes avec une fenêtre de maintenance complète.
Promotion de réplica (réplica fantôme / shadow replica) : basculement en 1 à 10 secondes. Faible risque. À utiliser pour les topologies autonomes ou Sentinel où la faible indisponibilité compte.
Double exécution (blue/green) + basculement : basculement en 1 à 30 secondes. Risque faible à moyen. À utiliser pour les applications complexes nécessitant une validation parallèle prolongée.
Mise à niveau cluster progressive (rolling cluster upgrade) par shard : 0,5 à 3 secondes par shard. Faible risque. À utiliser pour Redis Cluster avec des réplicas par master.

Les valeurs sont des exemples construits. Mesurez dans votre environnement. Privilégiez les méthodes basées sur les réplicas pour un risque faible et un retour arrière simple.

Considérations de configuration communes à toutes les méthodes

Maintenez l'authentification et les ACL (Access Control Lists) identiques sur les anciens et nouveaux hôtes avant le basculement (ACL LIST, ACL GETUSER, ACL SETUSER)
Faites correspondre le mode de persistance (RDB/AOF) pendant la réplication pour éviter les surprises au démarrage
Assurez-vous que repl-backlog-size est suffisant pour la fenêtre de réplication pendant la migration afin d'éviter les resynchronisations complètes
Utilisez un TTL (Time To Live) DNS bas (exemple : 30 s) pour un basculement client plus fluide

Guides pratiques

Cette section fournit des étapes concrètes pour les scénarios courants. Adaptez les noms d'hôtes, ports et chemins à votre environnement.

Guide A : Mise à niveau autonome via un réplica (faible indisponibilité)

Scénario : Mettre à niveau Redis 6.2 sur l'hôte old-redis:6379 vers Redis 7.x sur l'hôte new-redis:6379 avec un basculement de 5 secondes.

Préparer la cible avec une configuration identique

Copier redis.conf de l'ancien vers le nouveau et mettre à jour uniquement les chemins et les adresses de liaison si nécessaire
S'assurer que l'authentification et les ACL sont les mêmes avant la réplication

Démarrer le nouveau Redis en tant que réplica de l'ancien

Sur new-redis, définir replicaof et démarrer Redis 7.x :

     # Dans redis.conf sur new-redis
     replicaof old-redis 6379

Démarrer le service via votre gestionnaire de services système

Vérifier la synchronisation complète et la réplication en état stable

Sur new-redis :

     redis-cli INFO replication

Attendu : role:slave, master_link_status:up, master_sync_in_progress:0
Vérifier l'alignement des offsets de réplication sur les deux nœuds :

     redis-cli INFO replication | grep -E "offset|slave_repl_offset"

Échantillonnage en lecture seule (optionnel)

Exécuter des vérifications en lecture seule sur le réplica pour valider la présence des données et la latence de base :

     redis-cli -h new-redis DBSIZE
     redis-cli -h new-redis --latency-history --csv --raw

Basculement avec une courte pause d'écriture

Objectif : éviter la divergence pendant le changement
Sur old-redis, mettre en pause les nouvelles écritures brièvement :

     redis-cli CLIENT PAUSE 3000 WRITE

Promouvoir le réplica en master :

     redis-cli -h new-redis REPLICAOF NO ONE

Reconfigurer l'ancien master pour qu'il suive le nouveau master (garde le retour arrière facile) :

     redis-cli -h old-redis REPLICAOF new-redis 6379

Mettre à jour les clients (préférer la commutation DNS si utilisée). Garder le TTL bas à l'avance (exemple : 30 s)

Relâcher les écritures et valider

Sur old-redis :

     redis-cli CLIENT UNPAUSE

Confirmer les rôles :

     redis-cli -h new-redis ROLE
     redis-cli -h old-redis ROLE

Attendu : master sur new-redis, slave sur old-redis
Confirmer le succès des écritures sur new-redis :

     redis-cli -h new-redis SET upgrade:smoke 1
     redis-cli -h new-redis GET upgrade:smoke

Guide B : Mise à niveau progressive de Redis Cluster (basculement par shard)

Scénario : Cluster avec 3 masters, chacun avec 1 réplica ; mise à niveau de 6.x vers 7.x sans indisponibilité complète du cluster.

Choisir une paire de shards (master M1, réplica R1)

Mettre à niveau le réplica en premier vers 7.x (arrêter le service, mettre à niveau le binaire, démarrer le service)
Vérifier qu'il rejoint le cluster et se synchronise :

     redis-cli -p <port-R1> INFO replication

Promouvoir le réplica mis à niveau

Sur R1 :

     redis-cli -p <port-R1> CLUSTER FAILOVER

Attendre que R1 devienne master et M1 devienne réplica. Vérifier avec ROLE sur les deux.

Mettre à niveau l'ancien master (maintenant un réplica)

Arrêter M1, mettre à niveau vers 7.x, le démarrer et le laisser se synchroniser en tant que réplica.

Répéter par shard

Passer au shard 2 (M2/R2), puis au shard 3, en répétant le même motif.

Vérifications post-mise à niveau

Exécuter la validation du cluster :

     redis-cli --cluster check <n'importe-quel-nœud-hôte:port>

Confirmer le nombre de masters, de réplicas et la couverture des slots.

Guide C : Migration inter-environnements (même version ou saut de version)

Scénario : Déplacer Redis du DC-A vers le DC-B avec un saut de version, indisponibilité minimale.

Amorcer un réplica à travers les environnements

Dans le DC-B, démarrer Redis avec replicaof pointant vers le primaire du DC-A
S'assurer que les règles de pare-feu, la latence et la bande passante sont acceptables

Observer une réplication stable pendant au moins un cycle métier

Valider l'utilisation mémoire, les offsets de réplication et la stabilité de la latence

Planifier le basculement

Baisser le TTL DNS bien avant le basculement
Mettre en pause les écritures sur le DC-A pour quelques secondes :

     redis-cli -h dc-a-primary CLIENT PAUSE 3000 WRITE

Promouvoir le DC-B :

     redis-cli -h dc-b-replica REPLICAOF NO ONE

Reconfigurer le DC-A pour qu'il suive le DC-B :

     redis-cli -h dc-a-primary REPLICAOF <hôte-DC-B> 6379

Mettre à jour le DNS vers le DC-B

Surveiller et relâcher

Vérifier que l'application se reconnecte et que les commandes réussissent
Relâcher les écritures sur le DC-A et le conserver comme standby chaud temporaire pour le retour arrière

Vérification et diagnostics

La vérification prouve que la mise à niveau est correcte, pas seulement terminée.

Contrôles de base et résultats attendus

Version du serveur : redis-cli INFO server → redis_version affiche la version cible
Rôle et réplication : redis-cli INFO replication → role:master sur la cible ; réplicas connectés
Instantané présent : ls $(redis-cli CONFIG GET dir | tail -1)/dump.rdb → horodatage récent, taille non nulle
AOF activé (si utilisé) : redis-cli CONFIG GET appendonly → appendonly yes ou no selon le souhait
Parité de la taille du jeu de données : redis-cli DBSIZE → même nombre de clés ou supérieur après le basculement
Mix de commandes stable : redis-cli INFO commandstats → aucune commande inattendue manquante
Base de référence de latence : redis-cli --latency -h <hôte> -p <port> → similaire ou meilleure qu'avant la mise à niveau

Diagnostics opérationnels

INFO latency, memory, clients : bases de référence des plages acceptées
SLOWLOG GET 128 : s'assurer qu'aucune nouvelle commande lente n'a été introduite par la mise à niveau
LATENCY DOCTOR : triage rapide si des pics apparaissent
MONITOR est puissant mais lourd ; éviter en production en période de pointe

Sondage synthétique (à utiliser avec parcimonie)

Contre une fenêtre non critique, une petite sonde synthétique peut révéler des régressions :

redis-benchmark -h <hôte> -p 6379 -n 5000 -c 10 -t get,set

Garder les tests courts et à faible concurrence en production.

Vérification au niveau applicatif

Valider la connexion, les commandes de base et la gestion des erreurs depuis une instance d'application avant le déploiement global.

Test de connectivité Node.js :

const Redis = require('ioredis');
const r = new Redis({ host: 'new-redis', port: 6379, retryStrategy: null });
(async () => {
  await r.set('upgrade:node:smoke', 'ok', 'EX', 60);
  const v = await r.get('upgrade:node:smoke');
  console.log('Smoke value:', v);
  await r.quit();
})();

Capacité et marge mémoire

Après le basculement, s'assurer que used_memory < maxmemory * 0,7 (ligne directrice) pour laisser de l'espace aux réplicas et aux pics
Surveiller les métriques d'éviction : INFO stats → evicted_keys ne doit pas grimper de manière inattendue

Modes de défaillance et récupération

Anticipez les modes de défaillance suivants et préparez les réponses avant de commencer.

1. Le réplica ne rattrape jamais son retard (bande passante ou backlog insuffisant)

Symptôme : master_link_status fluctue ; master_sync_in_progress répète les synchronisations complètes
Action : augmenter repl-backlog-size, assurer la stabilité du réseau. Optionnellement amorcer avec une copie RDB pour réduire le coût de la synchronisation initiale :

  # Arrêter la cible, copier dump.rdb depuis la source, démarrer la cible comme réplica

2. Divergence de données pendant le basculement

Symptôme : clés manquantes ou écrasées sur le nouveau master après le basculement
Action : utiliser CLIENT PAUSE WRITE pendant le basculement pour vider les écritures. Si la divergence est détectée rapidement, revenir en arrière : promouvoir l'ancien master et repointer les clients.

3. Corruption AOF/RDB au démarrage (cible)

Symptôme : Redis refuse de démarrer ou plante en lisant les fichiers de persistance
Action : ne pas réparer sur place. Sur une copie, exécuter redis-check-rdb ou redis-check-aof. Remplacer le fichier corrompu par un instantané connu bon. Garder l'ancien master en service pendant la récupération.

4. Incompatibilité ACL ou authentification

Symptôme : les clients reçoivent NOAUTH ou NOPERM après le basculement
Action : exporter les ACLs de la source avant la migration et les importer sur la cible :

  # Source
  redis-cli ACL LIST > acls.txt
  # Cible
  # appliquer les commandes ACL SETUSER équivalentes

5. Régression de performance (pics de latence)

Symptôme : latence p50/p99 plus élevée, connexions perdues
Action : comparer la CONFIG, surtout maxmemory-policy, les réglages I/O et de persistance. Tester les deux états appendonly (on/off) s'ils ont changé. Revenir en arrière si la latence est inacceptable et que la cause racine est inconnue.

6. Problèmes de couverture des slots du cluster après mise à niveau progressive

Symptôme : redis-cli --cluster check montre des slots non assignés ou des nœuds en échec
Action : rajouter des réplicas si nécessaire, exécuter redis-cli --cluster fix <nœud>. S'assurer que chaque master a au moins un réplica sain avant de continuer.

7. Comportement de commande inattendu

Symptôme : comportement nouveau ou déprécié affectant la logique applicative
Action : valider le mix de commandes via INFO commandstats ; ajouter des tests d'intégration ciblés pour les commandes critiques. Si nécessaire, verrouiller sur une option de compatibilité connue sûre quand disponible, ou revenir en arrière le temps d'adapter.

Playbook de retour arrière (autonome ou Sentinel)

Garder l'ancien master en cours d'exécution comme réplica après le basculement pour un retour arrière rapide.

Pour revenir en arrière en quelques minutes :

Mettre en pause les écritures sur le nouveau master : CLIENT PAUSE 3000 WRITE
Repromouvoir l'ancien nœud en master : REPLICAOF NO ONE (sur l'ancien)
Pointer le nouveau nœud pour qu'il suive l'ancien : REPLICAOF <ancien> 6379
Mettre à jour le DNS vers l'ancien master
Relâcher les écritures sur l'ancien master

Playbook de retour arrière (Cluster)

Inverser le basculement de shard le plus récent :

Sur l'ancien master (maintenant réplica), s'assurer qu'il est mis à niveau et sain
Exécuter CLUSTER FAILOVER sur le réplica que vous souhaitez promouvoir
Vérifier la couverture des slots et la connectivité des clients

Critères de succès pour la récupération

Les clients se reconnectent dans le TTL attendu
Les taux d'erreurs de commande et les latences reviennent aux bases de référence d'avant le changement
La réplication se rétablit proprement dans la nouvelle topologie

Liste de contrôle opérationnelle

Utilisez cette liste comme un runbook reproductible.

Planification

Définir la version cible et les éléments du changelog pertinents pour votre charge de travail
Choisir un motif de migration (la promotion de réplica est le défaut pour un faible risque)
Définir une définition de succès mesurable (exemple : latence p95 dans les 10 % de la base de référence et zéro perte de données)
Baisser le TTL DNS avant le basculement si vous utilisez la commutation DNS

Pré-vol

Capturer les sorties INFO et configurations actuelles pour diff et retour arrière
Créer et vérifier un instantané RDB (et valider l'AOF si activé)
S'assurer que l'espace disque libre >= 1,5x le jeu de données sur la source et la cible
Aligner les ACLs et l'authentification sur la cible avec la source
Vérifier les chemins réseau et les règles de pare-feu pour la réplication

Exécution

Démarrer la cible comme réplica de la source ; vérifier que la synchronisation complète se termine
Observer les offsets de réplication et la stabilité sous charge typique
Optionnellement exécuter des requêtes de validation en lecture seule sur le réplica
Annoncer une brève fenêtre de basculement
Mettre en pause les écritures brièvement, promouvoir le réplica, repointer l'ancien master pour qu'il suive le nouveau master
Mettre à jour le DNS ou les points de terminaison de connexion

Vérification

Confirmer le rôle de la cible : master. Confirmer que les clients se sont reconnectés
Vérifier la parité DBSIZE et échantillonner des lectures de clés
Surveiller la latence (redis-cli --latency) pendant quelques minutes
Examiner SLOWLOG et INFO commandstats pour détecter des anomalies

Stabilisation

Garder l'ancien master comme réplica jusqu'à ce que vous soyez confiant dans la stabilité
Prendre un nouvel instantané sur le nouveau master
Rétablir les TTL DNS normaux

Post-mortem et durcissement

Enregistrer les durées, l'indisponibilité et les éventuels problèmes
Ajuster repl-backlog-size et la cadence des instantanés selon les besoins
Mettre à jour le runbook avec les leçons apprises

Conclusion

La mise à niveau ou la migration de Redis peut être prévisible, rapide et sûre lorsque vous faites l'inventaire de votre environnement, choisissez une approche réplica d'abord, validez avec des vérifications concrètes et gardez un retour arrière testé prêt. Commencez par un petit pilote inspectable pour confirmer votre approche, puis étendez en confiance en utilisant les mêmes étapes. Avec les guides pratiques, les diagnostics et les listes de contrôle de ce guide, vous pouvez réduire les risques tout en capturant les avantages des nouvelles versions de Redis.