Bonnes pratiques pour prévenir la perte de données : configuration RDB vs AOF

La persistance Redis est facile à mal comprendre car Redis ressemble à une base de données mais se comporte d'abord comme de la mémoire. Si vous le redémarrez sans persistance, les données sont perdues. Si la persistance est activée mais mal réglée, vous pouvez toujours perdre les écritures récentes, bloquer les clients en cas de pression disque, ou découvrir lors d'une panne que la seule copie de vos données se trouve sur le même volume défaillant que le processus Redis.

La bonne stratégie de perte de données Redis commence par une question honnête : que se passe-t-il si les dernières secondes, minutes ou heures d'écritures disparaissent ? Un cache de pages produit peut généralement être reconstruit. Un stockage de sessions peut ennuyer les utilisateurs mais ne détruit pas l'entreprise. Une file d'attente, un registre de limites de débit, un panier d'achat ou un stockage de fonctionnalités peut nécessiter une durabilité beaucoup plus stricte. RDB et AOF sont les deux outils que Redis vous offre, et ils résolvent différentes parties de ce problème.

Comprendre les mécanismes de persistance Redis

Redis a deux modes de persistance principaux :

Snapshots RDB

RDB écrit un instantané ponctuel du jeu de données sur le disque, généralement sous la forme dump.rdb. Redis fork un processus enfant, l'enfant sérialise le jeu de données, et le parent continue de servir les clients. Cela rend RDB utile pour les sauvegardes, les réplicas et les redémarrages rapides, mais il a un compromis clair : tout ce qui est écrit après le dernier snapshot réussi peut être perdu si le processus ou l'hôte tombe en panne.

Les paramètres RDB typiques ressemblent à ceci :

save 900 1       # Sauvegarde après 15 minutes si au moins 1 clé a changé
save 300 10      # Sauvegarde après 5 minutes si au moins 10 clés ont changé
save 60 10000    # Sauvegarde après 1 minute si au moins 10000 clés ont changé
dbfilename dump.rdb
dir /var/lib/redis

Ces lignes save ne sont pas une promesse que Redis sauvegardera exactement selon ce calendrier. Ce sont des règles de déclenchement : si suffisamment de clés ont changé pendant l'intervalle, Redis démarre une sauvegarde en arrière-plan. Si le disque est lent, le jeu de données est énorme, ou l'hôte manque de mémoire, la sauvegarde en arrière-plan peut échouer ou créer de la latence via la pression de fork et de copy-on-write.

RDB est le plus fort lorsque vous voulez des snapshots compacts et un comportement de restauration rapide. Il est le plus faible lorsque votre tolérance à la perte de données récentes est faible.

Journalisation AOF

AOF, ou persistance par fichier append-only, enregistre les commandes d'écriture afin que Redis puisse les rejouer au redémarrage. Il offre généralement une meilleure durabilité que RDB car il peut vider les écritures plus souvent qu'un planning de snapshots. Le compromis est plus d'E/S disque, des fichiers plus volumineux avant la réécriture, et parfois un démarrage plus lent si Redis doit rejouer un journal volumineux.

Les paramètres principaux sont :

appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
aof-auto-rewrite-percentage 100
aof-auto-rewrite-min-size 64mb
aof-rewrite-incremental-fsync yes

La ligne importante est appendfsync. Avec everysec, Redis demande au système d'exploitation de vider le AOF environ une fois par seconde. En cas de crash normal du processus Redis, cela limite généralement la perte à environ la dernière seconde d'écritures. En cas de crash complet de l'hôte ou de panne de stockage, la perte exacte dépend du système d'exploitation, du système de fichiers, du cache disque et du comportement de stockage, donc ne le décrivez pas comme une garantie mathématique.

appendfsync always vide après chaque écriture et est beaucoup plus coûteux. Il peut être approprié pour un petit déploiement Redis critique avec un volume d'écriture modeste, mais il peut gravement nuire à la latence sous un trafic réel. appendfsync no laisse le système d'exploitation décider quand vider ; c'est rapide, mais cela vous donne une fenêtre de perte beaucoup plus large et moins prévisible.

Bonnes pratiques pour la prévention des pertes de données

Utilisez les deux seulement lorsque vous comprenez quel fichier Redis chargera

De nombreux déploiements Redis en production activent à la fois RDB et AOF. C'est un défaut raisonnable lorsque Redis stocke des données qui seraient pénibles à reconstruire. RDB vous donne des artefacts de sauvegarde compacts. AOF vous donne une fenêtre de perte récente plus petite.

Utilisez une configuration comme celle-ci :

save 900 1
save 300 10
save 60 10000
appendonly yes
appendfsync everysec

Un détail compte lors de la restauration : lorsque AOF est activé, Redis charge normalement les données AOF au démarrage car on s'attend à ce qu'elles soient plus complètes que le snapshot RDB. Ne supposez pas que Redis chargera RDB en premier et se rabattra sur AOF. Testez le chemin de restauration pour votre version Redis et votre disposition de déploiement, en particulier sur les versions Redis qui utilisent le nouveau format AOF multi-parties.

Choisissez appendfsync à partir de la fenêtre de perte en arrière

Commencez par l'impact commercial, pas par le paramètre Redis.

Si Redis est un cache jetable, RDB seul peut suffire, ou même aucune persistance si votre application repeuple en toute sécurité. Si Redis contient des sessions, appendfsync everysec est souvent un équilibre pratique. Si Redis fait partie d'un flux de travail où la perte d'écritures accusées crée des dommages commerciaux réels, la persistance Redis seule peut ne pas être la bonne limite de durabilité. Vous pouvez avoir besoin d'une base de données primaire, d'une file d'attente durable, ou d'un comportement de journalisation préalable au niveau de l'application en dehors de Redis.

Pour la plupart des utilisations opérationnelles de Redis, commencez par :

appendonly yes
appendfsync everysec

Ensuite, surveillez la latence, le temps d'écriture disque, le comportement de réécriture AOF et le temps de redémarrage avant de décider de vous déplacer vers always ou de vous éloigner de AOF.

Gardez les snapshots RDB, mais ne les rendez pas trop agressifs

Des sauvegardes RDB fréquentes réduisent la quantité de données perdues entre les snapshots, mais elles augmentent également la fréquence des forks. Forker un grand processus Redis peut être coûteux, et les écritures pendant la sauvegarde enfant créent une pression mémoire copy-on-write. Si votre instance Redis a un jeu de données de 40 Go et que le taux d'écriture est élevé, sauvegarder chaque minute peut créer une fiabilité pire car l'hôte passe trop de temps sous pression mémoire et disque.

Des règles de sauvegarde RDB raisonnables dépendent du taux d'écriture et des attentes de récupération. Un petit cache peut prendre des snapshots souvent sans problème. Un grand stockage de sessions peut nécessiter moins de snapshots RDB plus AOF pour la durabilité récente. Surveillez INFO persistence, les logs Redis et la mémoire hôte pendant BGSAVE, pas seulement le fichier de configuration Redis.

Traitez la réécriture AOF comme une maintenance normale, pas une urgence

Les fichiers AOF grossissent car ils enregistrent les écritures. Redis les réécrit dans une représentation compacte en arrière-plan. Les valeurs par défaut sont souvent un bon point de départ :

aof-auto-rewrite-percentage 100
aof-auto-rewrite-min-size 64mb

Cela signifie que Redis envisage la réécriture lorsque le AOF a considérablement augmenté par rapport à la taille après la réécriture précédente, une fois qu'il a atteint la taille minimale. Si les réécritures se produisent constamment, augmentez la taille minimale ou enquêtez sur un modèle d'écriture bruyant. Si le AOF grossit longtemps sans réécriture, vérifiez les logs, l'espace disque et INFO persistence.

Vous pouvez déclencher une réécriture manuellement :

redis-cli BGREWRITEAOF

Faites-le pendant une période calme si possible. Une réécriture est plus sûre que de laisser le fichier grossir indéfiniment, mais elle consomme toujours du CPU, de la bande passante disque et de la mémoire copy-on-write.

Sauvegardez les fichiers de persistance ailleurs

La persistance n'est pas une sauvegarde. Les fichiers de persistance sur le même hôte vous protègent d'un redémarrage du processus Redis. Ils ne vous protègent pas d'un disque perdu, d'une suppression accidentelle, d'un mauvais déploiement qui écrase le répertoire de données, ou d'une erreur d'opérateur qui exécute FLUSHALL.

Copiez les fichiers RDB et AOF vers un stockage séparé. Si vous utilisez des snapshots de système de fichiers ou des snapshots de volume cloud, testez la restauration sur une instance séparée. Pour les copies RDB, préférez copier un fichier snapshot terminé plutôt qu'un fichier en cours d'écriture. Pour AOF, comprenez la disposition des fichiers pour votre version Redis avant de construire des scripts de sauvegarde autour des noms de fichiers.

Surveillez les signaux qui prédisent une perte de données

La commande utile lors d'un incident est :

redis-cli INFO persistence

Recherchez les sauvegardes en arrière-plan échouées, l'état de la réécriture AOF, l'heure de la dernière sauvegarde et les indicateurs de fsync retardé. Associez cela aux métriques de l'hôte : latence disque, espace disque libre, marge mémoire et événements OOM du noyau. Si BGSAVE échoue pendant des heures et que personne ne le remarque, la configuration Redis peut sembler sûre alors que le point de récupération réel devient de plus en plus ancien.

Utilisez la réplication ou Sentinel pour la disponibilité, pas comme votre seule sauvegarde

Les réplicas, Redis Sentinel et Redis Cluster aident à la disponibilité. Ils ne résolvent pas automatiquement tous les problèmes de perte de données. Une mauvaise écriture, une suppression accidentelle ou un bug d'application peuvent se répliquer rapidement. Le basculement peut également promouvoir un réplica qui manque d'écritures récentes en cas de retard de réplication. Gardez la persistance, les sauvegardes et les tests de restauration dans la conception.

La configuration pratique pour de nombreuses équipes est AOF avec appendfsync everysec, des snapshots RDB à un rythme raisonnable, des sauvegardes externes, une surveillance des échecs de persistance et un runbook de restauration testé. Redis peut être fiable sous cette forme, mais seulement si vous traitez la persistance comme un système opérationnel plutôt que comme une case à cocher.