Il existe deux options pour stocker les données de manière permanente dans Redis : AOF (Append-Only File) et RDB (Redis Database Snapshot). Dans un environnement opérationnel, il est courant de configurer les deux, mais de nombreux développeurs peuvent se poser les questions suivantes :

"Avec AOF qui enregistre les données en temps réel, la configuration RDB a-t-elle un sens ?" "Puisque AOF a la priorité pour la récupération, RDB n'est-il pas inutile ?"

Cependant, dans un environnement opérationnel, RDB est également nécessaire. Voyons pourquoi.

1. Le fichier AOF peut être corrompu

AOF enregistre toutes les modifications, mais il y a un risque de corruption de fichier. En cas de défaillance du disque, de panne durant l’opération, de déplacement incorrect de fichier, la corruption du fichier AOF peut rendre la récupération difficile.

redis-server --appendonly yes

Si le fichier AOF est corrompu lors du redémarrage de Redis, la récupération des données peut être impossible. Dans ce cas, des sauvegardes RDB peuvent permettre de récupérer au moins quelques données.

✅ Que se passe-t-il si j'utilise uniquement AOF et que le fichier est corrompu ? Risque accru de perte de données

✅ Et si j'ai RDB ? Possibilité de récupérer au moins des données minimales

2. La vitesse de récupération AOF est lente

AOF doit réexécuter toutes les modifications une par une pour récupérer. Plus il y a de données, plus le temps de récupération lors du redémarrage de Redis peut être long.

Par exemple, si le fichier AOF fait 2 Go, Redis doit exécuter des millions de commandes SET. En revanche, RDB peut être récupéré beaucoup plus rapidement en chargeant simplement le fichier de dump.

✅ Si j'utilise uniquement AOF ? Risque d'augmentation du temps de récupération

✅ Et si j'utilise RDB en plus ? Récupération rapide possible

3. RDB est avantageux pour les sauvegardes et la migration de serveur

Lors de la sauvegarde des données dans un environnement opérationnel, AOF a un grand taille de fichier et un format de journal qui complicate son utilisation. En revanche, RDB a une taille de fichier plus petite et peut conserver les données d'un момент spécifique, ce qui facilite la sauvegarde.

✔ Exemple de sauvegarde avec RDB :

cp /var/lib/redis/dump.rdb /backup/dump-2025-02-17.rdb

✔ Exemple de transfert de données vers un autre serveur :

scp /var/lib/redis/dump.rdb new-server:/var/lib/redis/

✅ AOF devient de plus en plus difficile à sauvegarder avec un volume de données élevé

✅ RDB est favorable pour sauvegarder et restaurer rapidement les données à un момент spécifique

4. Réduction de la charge I/O disque

AOF doit enregistrer toutes les modifications sur le disque, ce qui entraîne une charge I/O disque élevée. En revanche, RDB ne fait qu'un enregistrement à des intervalles réguliers, ce qui réduit la charge sur le disque.

✅ Si j'utilise uniquement AOF ? Risque d'augmentation de la charge sur le disque

✅ Et en utilisant RDB ensemble ? Optimisation des performances possible

5. Configuration RDB + AOF recommandée en production

Nous recommandons la configuration suivante dans un environnement opérationnel.

# Configuration de snapshot RDB (sauvegarde des données sur le disque lorsque certaines conditions sont remplies)
# save <seconds> <changes> [<seconds> <changes> ...]
save 900 1 300 10 60 10000 
# Sauvegarde après plus de 900 secondes (15 minutes) avec 1 ou plus de modifications de clé, ou plus de 300 secondes (5 minutes) avec 10 ou plus de modifications de clé, ou plus de 60 secondes (1 minute) avec 10 000 ou plus de modifications de clés

# Activation de AOF
appendonly yes
appendfsync everysec  # Enregistrement sur le disque chaque seconde pour équilibrer performance et stabilité

# Optimisation automatique de la taille du fichier AOF (réécriture)
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

🔍 Comment les multiples conditions save sont-elles évaluées ?

Dans Redis, toutes les save conditions fonctionnent comme un condition OR. En d'autres termes, si une seule condition est satisfaite, le snapshot est sauvegardé.

✔ Exemple 1 : si les conditions save 900 1 et save 60 10000 sont établies - Si une ou plusieurs modifications ont lieu durant 900 secondes, ou - Si plus de 10 000 modifications ont eu lieu durant 60 secondes, - Un snapshot RDB sera sauvegardé.

✔ Exemple 2 : si la condition save 300 10 est ajoutée - Si plus de 10 modifications ont eu lieu durant 300 secondes, ou - Si une ou plus de modifications ont eu lieu durant 900 secondes, ou - Si plus de 10 000 modifications ont eu lieu durant 60 secondes, - Un snapshot RDB sera sauvegardé.

✅ Toutes les options save sont évaluées avec un condition OR

✅ Si une seule est satisfaite, le RDB est sauvegardé immédiatement

Conclusion : AOF peut être là, mais RDB est toujours nécessaire

✅ La protection des données n'est pas parfaite avec seulement AOF

✅ En cas de corruption de AOF, RDB joue le rôle de sauvegarde ultime

✅ La vitesse de récupération AOF peut être lente, donc utiliser RDB permet une récupération rapide

✅ RDB est avantageux pour les sauvegardes et la migration de serveur

✅ Peut réduire la charge I/O disque et optimiser les performances

✅ Les réglages save fonctionnent avec des conditions OR afin que si une seule est remplie, le RDB est sauvegardé

Par conséquent, dans un environnement opérationnel, configurer RDB + AOF ensemble est la méthode la plus sûre et optimale.

Utilisez la barre de recherche à droite pour rechercher `Redis` ! D'autres articles liés à Redis sont accessibles.

Consultez également notre article précédent sur l’analyse de la fonction de réécriture AOF.

Redis AOF Rewrite : optimisation des performances et conservation des données