data / redis
Persistance : RDB et AOF
Explication
Ce que vous allez apprendre
- Comprendre pourquoi une base entièrement en mémoire a besoin d'un mécanisme de persistance
- Configurer des snapshots RDB périodiques et déclencher un snapshot manuel avec
BGSAVE - Configurer l'AOF (journal d'écriture) et choisir le bon compromis de fréquence de fsync
- Comparer RDB et AOF sur la perte de données possible, la taille et la vitesse de redémarrage
- Combiner les deux mécanismes, la pratique recommandée en production
Dans quel contexte ?
Un serveur Redis en production héberge le cache de sessions ET des compteurs métier importants (crédits utilisateurs, par exemple). Une coupure électrique inattendue redémarre brutalement le serveur : sans aucune persistance configurée, toutes les données en mémoire sont perdues intégralement, y compris des informations qu'il aurait été problématique de perdre.
D'abord, pourquoi une base en mémoire a structurellement besoin de ce mécanisme
Tout ce qui vit uniquement en RAM disparaît à l'extinction du processus, qu'elle soit volontaire (redémarrage planifié) ou accidentelle (crash, coupure électrique). Redis propose deux mécanismes de persistance sur disque, avec des compromis différents, pour retrouver tout ou partie des données après un redémarrage.
Une fois ce besoin identifié, la première approche est le snapshot périodique (RDB)
RDB (Redis Database) prend une photo complète de l'état de la base à intervalles réguliers, définis par des règles comme save 300 10 (snapshot si au moins 10 clés ont changé en 5 minutes). C'est un fichier binaire compact, rapide à charger au redémarrage, mais qui perd inévitablement toutes les modifications survenues depuis le dernier snapshot en cas de crash.
Ensuite, une seconde approche répond au problème de perte de données du snapshot
L'AOF (Append Only File) journalise chaque commande d'écriture au fur et à mesure, un peu comme un journal de bord continu. Avec appendfsync everysec, la perte de données maximale en cas de crash se limite à environ une seconde d'écritures, bien plus fin que l'intervalle entre deux snapshots RDB.
| Critère | RDB | AOF |
|---|---|---|
| Perte de données max en cas de crash | Depuis le dernier snapshot (minutes) | ~1 seconde avec everysec |
| Taille du fichier | Compacte | Plus volumineuse (journal complet) |
| Vitesse de redémarrage | Rapide (chargement direct) | Plus lente (rejoue chaque commande) |
| Impact en fonctionnement | Pic ponctuel CPU/IO au moment du fork | Overhead continu, léger |
Il reste un choix de compromis à faire consciemment sur la fréquence de synchronisation AOF
appendfsync always écrit sur disque à chaque commande, ce qui est extrêmement durable mais ralentit fortement chaque écriture. appendfsync no laisse le système d'exploitation décider quand écrire réellement, ce qui est rapide mais expose à une perte de données plus importante en cas de crash. everysec, le réglage par défaut recommandé, offre le meilleur compromis pour la grande majorité des cas d'usage.
Prérequis
Cette leçon suppose que tu comprends déjà que Redis stocke tout en mémoire par défaut (leçon 1) : la persistance est précisément le mécanisme qui compense cette caractéristique structurelle.
Piège fréquent
Déclencher SAVE (la version synchrone, pas BGSAVE) sur une base volumineuse en production bloque complètement le serveur pendant toute la durée du snapshot, refusant toute autre commande entre-temps. BGSAVE, qui utilise un fork du processus pour travailler en arrière-plan, doit toujours être préféré en production.
Bonne pratique
En production, combine RDB et AOF plutôt que de choisir l'un ou l'autre : RDB apporte des sauvegardes compactes et une restauration rapide, AOF apporte une durabilité fine. Cette combinaison, illustrée par appendonly yes avec des règles save en complément, est la configuration recommandée pour la plupart des déploiements sérieux.
Maintenant que tes données survivent à un redémarrage, la prochaine leçon aborde la haute disponibilité au niveau serveur : la réplication maître-répliquas, pour répartir la lecture et préparer un futur failover.
Commandes & code
Persistance : RDB et AOF
# RDB (Redis Database) : snapshot binaire complet à intervalles réguliers
# AOF (Append Only File) : journal de toutes les commandes d'écriture, rejouable# --- Configuration RDB (redis.conf) ---
# save <secondes> <nb_changements> -> déclenche un snapshot si N écritures en X secondes
save 900 1 # snapshot si au moins 1 clé modifiée en 15 minutes
save 300 10 # snapshot si au moins 10 clés modifiées en 5 minutes
save 60 10000 # snapshot si au moins 10000 clés modifiées en 1 minute
dbfilename dump.rdb
dir /var/lib/redis
# Déclencher un snapshot manuellement
BGSAVE # asynchrone, ne bloque pas le serveur (fork du process)
SAVE # synchrone, BLOQUE le serveur : à éviter en production
LASTSAVE # timestamp du dernier snapshot réussi
# --- Configuration AOF (redis.conf) ---
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec # compromis par défaut : fsync toutes les secondes
# appendfsync always # fsync à CHAQUE écriture : très durable, très lent
# appendfsync no # laisse l'OS décider : rapide, risque de perte plus élevé
# Réécrire l'AOF pour le compacter (supprime l'historique redondant)
BGREWRITEAOF
# Vérifier/réparer un fichier AOF corrompu
redis-check-aof --fix appendonly.aof
redis-check-rdb dump.rdb| Critère | RDB | AOF |
|---|---|---|
| Perte de données max | depuis le dernier snapshot | ~1s (avec everysec) |
| Taille fichier | compacte | plus volumineux (journal complet) |
| Vitesse redémarrage | rapide | plus lent (rejoue les commandes) |
| Impact performance | pic CPU/IO au fork | overhead continu léger |
# Combiner les deux (recommandé en production) : AOF pour la durabilité, RDB pour les sauvegardes/restaurations rapides
appendonly yes
save 3600 1Résumé
- RDB fait des snapshots complets périodiques ; AOF journalise chaque écriture pour une durabilité fine.
appendfsync everysecest le meilleur compromis durabilité/performance pour la plupart des cas.- En production, combiner RDB (sauvegardes/restauration rapide) et AOF (durabilité) est la pratique recommandée.
Exercices pratiques
Mission : sauver les crédits utilisateurs après une coupure électrique surprise
Objectif : Diagnostiquer un choix de persistance inadapté, configurer une sauvegarde manuelle sans bloquer le serveur, et anticiper le risque mémoire d'un BGSAVE en pleine charge.
Contexte
Un serveur Redis héberge à la fois le cache de sessions et les crédits utilisateurs, avec seulement save 300 10 configuré (aucun AOF). Une coupure électrique survient, et un collègue a par ailleurs récemment déclenché un SAVE synchrone en pleine journée, bloquant l'API plusieurs secondes. Tu dois diagnostiquer les pertes possibles et corriger les pratiques de sauvegarde.