Mise à niveau et migration Redis avec exemples pratiques : guide d'implémentation

Introduction

Mettre à niveau ou migrer Redis doit améliorer sécurité, stabilité et performance sans perturber vos applications. Le risque ne vient pas tant de la nouvelle version que d'un changement non planifié. Ce guide décrit comment planifier et exécuter une mise à niveau Redis à faible risque, valider chaque étape, et revenir en arrière (rollback) en toute sécurité si besoin. Vous allez inventorier votre environnement, choisir un chemin sûr, suivre des exemples concrets pour Standalone, Sentinel et Cluster, puis conclure avec diagnostics, modes de panne et une checklist réutilisable.

Inventaire des versions et de l'environnement

Des mises à niveau solides commencent avec des faits clairs. Capturez ces éléments avant tout changement en production.

Prérequis et accès

• Accès shell aux hôtes Redis.
• Capacité à mettre à jour la configuration et à redémarrer Redis pendant un créneau de maintenance si nécessaire.
• Accès au DNS ou au service de découverte pour le basculement des clients.
• Espace disque suffisant pour un instantané complet supplémentaire (prévoyez au moins dataset_size × 1,5 d'espace libre).

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

• Version binaire :
• redis-server -v
• Détails serveur (build, chemin du fichier de conf) :
• redis-cli INFO server
• Mode de persistance et planification des snapshots :
• redis-cli CONFIG GET appendonly
• redis-cli CONFIG GET save
• Taille de dataset 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

• Standalone : un primaire, éventuellement des réplicas.
• Sentinel : haute disponibilité avec primaires et réplicas gérés par Sentinel.
• Cluster : déploiement shardé avec masters et replicas.

Considérations côté application

• Bibliothèques clientes et chaînes de connexion (auth, TLS, timeouts, stratégies de retry).
• Politique d'éviction et limites mémoire (CONFIG GET maxmemory, maxmemory-policy).
• Temps d'arrêt acceptable et stratégie de basculement (DNS, réutilisation de connexions, failover orchestré).

Sauvegardes et contrôles d'intégrité

• Créez un snapshot RDB propre :
• redis-cli BGSAVE
• Vérifiez l'existence et l'horodatage dans le répertoire de CONFIG GET dir
• Si AOF est activé, validez-le hors ligne sur une copie :
• redis-check-aof --fix appendonly.aof (sur une copie, jamais en place)
• Validez le RDB hors ligne sur une copie :
• redis-check-rdb dump.rdb

Interrupteurs de sécurité à noter

• stop-writes-on-bgsave-error doit être yes pour la sécurité (CONFIG GET stop-writes-on-bgsave-error).
• appendfsync par défaut everysec offre un bon compromis durabilité/performance.

Chemin de configuration sûr

Choisissez une approche adaptée à votre topologie et à votre tolérance au risque. Les modèles suivants couvrent la majorité des cas réels.

Tableau comparatif (valeurs construites, mesurez chez vous) :

Notes

• Les valeurs sont des exemples construits. Mesurez dans votre environnement.
• Préférez les méthodes basées sur des réplicas pour un risque réduit et un rollback simple.

Considérations de configuration communes

• Conservez une authentification et des ACL identiques entre anciens et nouveaux hôtes avant le cutover (ACL LIST, ACL GETUSER, ACL SETUSER).
• Faites correspondre le mode de persistance (RDB/AOF) durant la réplication pour éviter les surprises au démarrage.
• Assurez un repl-backlog-size suffisant pour la fenêtre de réplication et éviter les resync complets.
• Utilisez un TTL DNS bas (ex. 30 s) pour un basculement clients plus souple.

Parcours pratiques

Ajustez hôtes, ports et chemins à votre environnement.

Parcours A : Standalone via réplica (faible downtime)

Scénario (exemple) : Mettre à niveau Redis 6.2 sur old-redis:6379 vers Redis 7.x sur new-redis:6379 avec 5 secondes de cutover.

1. Préparer la cible avec une config cohérente

• Copiez redis.conf de l'ancien vers le nouveau et n'ajustez que les chemins et adresses bind nécessaires.
• Assurez l'alignement de l'authentification et des ACL avant la réplication.

1. Démarrer le nouveau Redis comme réplica de l'ancien

• Sur new-redis, définissez replicaof et démarrez Redis 7.x :
• Dans redis.conf de new-redis : replicaof old-redis 6379
• Démarrez le service (via votre gestionnaire de services OS)

1. Vérifier la synchronisation complète et l'état stable

• Sur new-redis :
• redis-cli INFO replication
• Attendu : role: slave, master_link_status: up, master_sync_in_progress:0
• Vérifiez l'alignement des offsets de réplication :
• Sur les deux nœuds : redis-cli INFO replication | grep -E "offset|slave_repl_offset"

1. Échantillonnage en lecture seule (optionnel)

• Exécutez des vérifications en lecture 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

1. Cutover avec courte pause d'écriture

• Objectif : éviter une divergence pendant le switch.
• Sur old-redis, mettez en pause les nouvelles écritures :
• redis-cli CLIENT PAUSE 3000 WRITE
• Promouvez le réplica en master :
• redis-cli -h new-redis REPLICAOF NO ONE
• Reconfigurez l'ancien master pour suivre le nouveau (rollback simplifié) :
• redis-cli -h old-redis REPLICAOF new-redis 6379
• Mettez à jour les clients (idéalement via DNS, TTL faible préparé en amont).

1. Débloquez les écritures et validez

• Sur old-redis : redis-cli CLIENT UNPAUSE
• Confirmez les rôles :
• redis-cli -h new-redis ROLE (doit être master)
• redis-cli -h old-redis ROLE (doit être slave)
• Validez les écritures côté new-redis :
• redis-cli -h new-redis SET upgrade: smoke 1
• redis-cli -h new-redis GET upgrade: smoke

Parcours B : Rolling upgrade Redis Cluster (failover par shard)

Scénario (exemple) : Cluster avec 3 masters, chacun avec 1 réplica ; mise à niveau de 6.x vers 7.x sans arrêt total du cluster.

1. Sélectionnez une paire de shard (master M1, réplica R1)

• Mettez à niveau le réplica vers 7.x (arrêt, upgrade binaire, redémarrage).
• Vérifiez qu'il rejoint et se synchronise : redis-cli -p <R1-port> INFO replication

1. Promouvez le réplica mis à niveau

• Sur R1 : redis-cli -p <R1-port> CLUSTER FAILOVER
• Attendez que R1 devienne master et M1 réplica. Vérifiez avec ROLE sur les deux.

1. Mettez à niveau l'ancien master (désormais réplica)

• Arrêtez M1, mettez à niveau en 7.x, redémarrez-le et laissez-le se resynchroniser en tant que réplica.

1. Répétez par shard

• Passez au shard 2 (M2/R2), puis shard 3, en répétant le même schéma.

1. Contrôles post-upgrade

• redis-cli --cluster check <any-node-host: port>
• Confirmez le nombre de masters, réplicas et la couverture des slots.

Parcours C : Migration inter-environnements (même version ou + version)

Scénario (exemple) : Déplacer Redis de DC-A vers DC-B avec une montée de version et un downtime minimal.

1. Amorcer un réplica entre environnements

• Dans DC-B, démarrez Redis avec replicaof pointant vers le primaire de DC-A.
• Assurez règles firewall et latence/bande passante acceptables.

1. Observer une réplication stable sur un cycle métier

• Validez l'usage mémoire, les offsets de réplication et la stabilité de latence.

1. Planifier le cutover

• Abaissez le TTL DNS bien avant le cutover.
• Pause d'écritures côté DC-A : CLIENT PAUSE 3000 WRITE
• Promotion côté DC-B : REPLICAOF NO ONE
• Reconfigurez DC-A pour suivre DC-B : REPLICAOF <DC-B> 6379
• Mettez à jour le DNS vers DC-B.

1. Surveiller et débloquer

• Vérifiez la reconnexion applicative et le succès des commandes.
• Débloquez les écritures sur DC-A et conservez-le en hot standby temporairement pour un rollback rapide.

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

| Snapshot 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 souhait | | Parité dataset | redis-cli DBSIZE | Compte de clés identique ou supérieur après cutover | | Mix de commandes stable | redis-cli INFO commandstats | Pas de commandes manquantes inattendues | | Latence de base | redis-cli --latency -h <host> -p <port> | Similaire ou meilleure qu'avant |

Diagnostics opérationnels

• INFO latency, memory, clients : conservez des plages de référence.
• SLOWLOG GET 128 : s'assurer qu'aucune commande lente nouvelle n'apparaît.
• LATENCY DOCTOR : triage rapide en cas de pics.
• MONITOR est puissant mais coûteux ; évitez en pic de prod.

Sonde synthétique (avec parcimonie)

• Sur une fenêtre non critique, une petite sonde peut révéler des régressions :
• redis-benchmark -h <host> -p <port> -n 5000 -c 10 -t get, set
• Gardez des tests courts et à faible concurrence en production.

Vérification côté application

• Validez connexion, commandes de base et gestion d'erreurs depuis une instance applicative avant un déploiement global.
• Exemple Node.js (ioredis) de test de fumée :

// Exemple Node.js avec ioredis (extrait construit)
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 cutover, assurez used_memory < maxmemory * 0.7 (guideline construite) pour garder de la marge pour réplicas et pics.
• Surveillez l'éviction : INFO stats -> evicted_keys ne doit pas augmenter de façon inattendue.

Pannes et récupération

Anticipez ces échecs et préparez vos réponses.

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

• Symptôme : master_link_status fluctue ; master_sync_in_progress relance des synchronisations complètes.
• Action : augmentez repl-backlog-size, stabilisez le réseau. Option : amorcer avec une copie RDB pour réduire le coût de sync initiale (arrêter la cible, copier dump.rdb, redémarrer comme réplica).

1. Divergence de données pendant le cutover

• Symptôme : clés manquantes/écrasées sur le nouveau master après cutover.
• Action : utilisez CLIENT PAUSE WRITE pour drainer les écritures. Si divergence détectée rapidement, rollback : re-promouvez l'ancien master et repointez les clients.

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

• Symptôme : Redis refuse de démarrer ou plante en lisant la persistance.
• Action : ne réparez pas en place. Sur une copie, lancez redis-check-rdb ou redis-check-aof. Remplacez par un snapshot sain. Gardez l'ancien master en service pendant la récupération.

1. Décalage d'ACL ou d'auth

• Symptôme : clients reçoivent NOAUTH ou NOPERM après cutover.
• Action : exportez les ACL depuis la source et appliquez-les sur la cible :
• Source : redis-cli ACL LIST > acls.txt
• Cible : appliquez ACL SETUSER équivalents.

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

• Symptôme : p50/p99 en hausse, connexions perdues.
• Action : comparez la CONFIG, notamment maxmemory-policy, E/S et persistance. Testez appendonly (on/off) si modifié. Faites un rollback si la latence est inacceptable sans cause racine claire.

1. Problèmes de couverture de slots après rolling upgrade (Cluster)

• Symptôme : redis-cli --cluster check signale des slots non assignés ou des nœuds en échec.
• Action : réajoutez des réplicas si nécessaire, exécutez redis-cli --cluster fix <node>. Garantissez au moins un réplica sain par master avant de continuer.

1. Comportements de commande inattendus

• Symptôme : évolution/dépréciation affectant la logique applicative.
• Action : validez le mix via INFO commandstats ; ajoutez des tests d'intégration ciblés pour les commandes critiques. Si besoin, utilisez une option de compatibilité appropriée ou faites un rollback pendant l'adaptation.

Playbook de rollback (Standalone ou Sentinel)

• Conservez l'ancien master en réplica après cutover pour un rollback rapide.
• Pour revenir en quelques minutes :

1. Pause d'écritures sur le nouveau master : CLIENT PAUSE 3000 WRITE
2. Re-promouvez l'ancien nœud : REPLICAOF NO ONE (sur l'ancien)
3. Pointez le nouveau vers l'ancien : REPLICAOF <old> 6379
4. Restaurez le DNS vers l'ancien master
5. Débloquez les écritures sur l'ancien master

Playbook de rollback (Cluster)

• Inversez le dernier failover de shard :

1. Sur l'ancien master (devenu réplica), vérifiez qu'il est sain
2. CLUSTER FAILOVER sur le réplica à re-promouvoir
3. Vérifiez la couverture de slots et la connectivité clients

Critères de succès du rétablissement

• Les clients se reconnectent dans le TTL attendu.
• Le taux d'erreurs et les latences reviennent aux niveaux de référence.
• La réplication se rétablit proprement dans la nouvelle topologie.

Checklist d'exploitation

Utilisez cette checklist comme runbook réutilisable.

Planification

• Définissez la version cible et les points de changelog pertinents.
• Choisissez un modèle de migration (promotion de réplica par défaut pour faible risque).
• Définissez un succès mesurable (ex. p95 dans ±10 % du baseline, zéro perte de données).
• Abaissez le TTL DNS avant le cutover si vous utilisez le DNS.

Préflight

• Capturez les sorties INFO et configs actuelles pour diff et rollback.
• Créez et validez un snapshot RDB (et AOF si activé).
• Vérifiez un espace libre ≥ 1,5× dataset sur source et cible.
• Alignez ACL et authentification sur la cible avec la source.
• Vérifiez les chemins réseau et règles firewall pour la réplication.

Exécution

• Démarrez la cible comme réplica de la source ; vérifiez la fin de la sync complète.
• Observez les offsets de réplication et la stabilité en charge normale.
• Optionnel : requêtes de validation en lecture sur le réplica.
• Annoncez une courte fenêtre de cutover.
• Pause d'écritures, promotion du réplica, re-pointage de l'ancien master vers le nouveau.
• Mettez à jour DNS ou endpoints de connexion.

Vérification

• Confirmez le rôle master côté cible. Confirmez la reconnexion des clients.
• Vérifiez la parité DBSIZE et échantillonnez des lectures de clés.
• Surveillez la latence (redis-cli --latency) quelques minutes.
• Passez en revue SLOWLOG et INFO commandstats pour anomalies.

Stabilisation

• Conservez l'ancien master en réplica jusqu'à stabilisation confirmée.
• Prenez un nouveau snapshot côté nouveau master.
• Restaurez des TTL DNS normaux.

Post-mortem et durcissement

• Documentez timing, downtime et incidents.
• Ajustez repl-backlog-size et la cadence de snapshots si nécessaire.
• Mettez à jour le runbook selon les leçons apprises.

Conclusion

La mise à niveau ou la migration Redis peut être prévisible, rapide et sûre si vous inventorie z votre environnement, choisissez un chemin centré sur le réplica, validez avec des contrôles concrets et gardez un rollback Redis testé. Commencez par un pilote limité et observable pour confirmer votre approche, puis étendez avec confiance en réutilisant les mêmes étapes. Avec ces parcours, diagnostics et checklists, vous réduisez le risque tout en capturant les bénéfices des nouvelles versions de Redis.