## 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 INFO replication - Promouvoir le réplica mis à niveau - Sur R1 : redis-cli -p 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 - 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 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 -p → 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 -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 ## 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 . 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 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.