Options de persistance Redis : RDB vs AOF expliqués

La persistance Redis détermine la quantité de données que votre serveur Redis peut récupérer après un redémarrage ou un crash. Les deux options principales sont les instantanés RDB et les journaux AOF, et le bon choix dépend de la quantité de données récentes que votre application peut se permettre de perdre.

Redis conserve les données en mémoire pour la rapidité. La persistance écrit suffisamment d'état sur le disque pour que Redis puisse reconstruire ces données plus tard. Vous pouvez utiliser RDB, AOF, les deux, ou aucun, mais les systèmes de production doivent faire ce choix délibérément.

Comprendre la persistance Redis

La persistance dans Redis fait référence au processus d'écriture de l'état actuel de l'ensemble de données en mémoire sur le disque. Cela permet à Redis de recharger les données lorsque le serveur redémarre. Sans persistance activée, toutes les données sont perdues lors de l'arrêt.

Redis prend en charge à la fois RDB et AOF simultanément, offrant une approche hybride qui combine les meilleures fonctionnalités des deux.

Instantanés RDB

RDB crée des instantanés ponctuels de votre ensemble de données et les écrit dans un fichier binaire compact, généralement nommé dump.rdb.

Comment fonctionne RDB

RDB fonctionne normalement en forquant le processus Redis. Le processus enfant écrit l'ensemble de données sur le disque tandis que le parent continue de servir les clients. Parce que RDB est un instantané, il capture les données telles qu'elles existaient à un moment donné.

Configuration et création d'instantanés

La configuration RDB est gérée avec des directives save dans redis.conf. Ces directives définissent quand Redis doit créer un instantané automatique :

# Sauvegarder la base de données si 1000 clés ont changé en 1 minute
save 600 1000
# Sauvegarder la base de données si 10 clés ont changé en 10 minutes
save 300 10
# Sauvegarder la base de données si 10000 clés ont changé en 1 seconde
save 1 10000

Pour désactiver les instantanés RDB automatiques, supprimez les directives save ou définissez :

save ""

Vous pouvez toujours déclencher un instantané manuel en arrière-plan avec BGSAVE lorsque vous en avez besoin.

Avantages de RDB

Fichiers compacts : Les fichiers RDB sont efficaces pour les sauvegardes, les copies et les archives de reprise après sinistre.
Récupération rapide : Charger un instantané est généralement plus rapide que de rejouer un long journal de commandes.
Faible surcharge d'écriture constante : Redis n'écrit pas chaque commande dans le fichier de persistance.

Inconvénients de RDB

Risque de perte de données : Si Redis plante entre les instantanés, les écritures après le dernier instantané réussi sont perdues.
Surcharge de forking : Les grands ensembles de données peuvent rendre fork() coûteux et provoquer des pics de latence.
Pas un journal d'audit complet : RDB stocke l'état final, pas chaque écriture qui y a conduit.

Journaux AOF

AOF (fichier d'ajout uniquement) offre un niveau plus élevé de durabilité des données. Au lieu d'instantanés, AOF enregistre chaque opération d'écriture reçue par le serveur dans un format d'ajout uniquement.

Comment fonctionne AOF

Lorsque AOF est activé, Redis enregistre les commandes d'écriture telles que SET, HSET et LPUSH dans un fichier d'ajout uniquement. Au redémarrage, Redis rejoue ce fichier pour reconstruire l'ensemble de données.

Configuration AOF

La persistance AOF est désactivée par défaut et doit être explicitement activée dans redis.conf :

appendonly yes

Crucialement, AOF permet la configuration de la politique fsync, déterminant la fréquence à laquelle les écritures sont forcées sur le disque :

Politique fsync	Description	Durabilité vs. Performance
`no`	Le système d'exploitation gère la synchronisation (moins fréquente).	Le plus rapide, risque de perte le plus élevé.
`everysec`	Synchronisation environ une fois par seconde.	Bon équilibre. Limite généralement la perte à environ une seconde lors d'un crash serveur.
`always`	Synchronisation après chaque commande.	Durabilité la plus élevée, impact potentiel significatif sur les performances.

Avantages de AOF

Durabilité plus élevée : appendfsync everysec est un équilibre de production courant ; always est plus strict mais plus lent.
Intention lisible : AOF stocke les commandes d'écriture, il peut donc être plus facile à inspecter qu'un fichier binaire RDB.
Compaction automatique : La réécriture AOF peut réduire un grand journal aux commandes minimales nécessaires pour reconstruire l'état actuel.

Inconvénients de AOF

Fichiers plus volumineux : Les fichiers AOF sont souvent plus grands que les instantanés RDB car ils stockent les commandes.
Redémarrage plus lent : Rejouer un long AOF peut prendre plus de temps que de charger un instantané RDB.
Plus de surcharge d'écriture : Redis doit ajouter les commandes d'écriture et les synchroniser selon votre paramètre appendfsync.

Réécriture AOF

Pour lutter contre la croissance de la taille des fichiers, Redis implémente la réécriture AOF. Ce processus crée de manière asynchrone un nouveau fichier AOF optimisé contenant uniquement les commandes nécessaires pour atteindre l'état actuel, éliminant efficacement les commandes redondantes ou obsolètes (comme les mises à jour multiples de la même clé).

RDB vs. AOF : Comparaison directe

Choisir entre RDB, AOF ou les deux dépend entièrement des exigences de votre application en matière de temps de récupération et de tolérance à la perte de données.

Fonctionnalité	RDB (Instantanés)	AOF (Fichier d'ajout uniquement)
Durabilité/Perte de données	Perte de données potentielle plus élevée (depuis la dernière sauvegarde).	Perte de données minimale (jusqu'à 1 seconde, ou zéro avec `fsync=always`).
Taille du fichier	Très compact et optimisé.	Plus volumineux en raison de la journalisation des commandes.
Temps de redémarrage	Chargement très rapide de l'instantané.	Plus lent, nécessite la relecture des commandes.
Complexité	Simple, configuré par intervalles de temps.	Nécessite une configuration minutieuse de la politique `fsync`.
Cas d'utilisation	Sauvegardes, reprise après sinistre où la perte de données récentes est tolérable.	Mécanisme de persistance principal nécessitant une durabilité élevée.

Meilleure pratique : Combiner RDB et AOF

Pour de nombreux déploiements de production, activer à la fois RDB et AOF vous offre un filet de sécurité utile.

Lorsque les deux sont activés :

AOF fournit le journal principal à haute durabilité.
RDB fournit un instantané de sauvegarde rapide et compact.

Lorsque les deux sont activés, Redis charge l'AOF au redémarrage car il est généralement plus complet que le dernier instantané RDB. RDB vous donne toujours des fichiers de sauvegarde compacts faciles à copier, tester et archiver.

Comment activer les deux

Assurez-vous que les deux configurations sont définies dans redis.conf :

# Activer AOF
appendonly yes

# Conserver la configuration RDB (par exemple, sauvegarde automatique toutes les heures)
save 3600 1

# Politique fsync recommandée pour AOF
appendfsync everysec

Astuce sur la réécriture AOF : Vous pouvez déclencher manuellement une réécriture AOF à tout moment en utilisant la commande BGREWRITEAOF. Cela est particulièrement utile après des chargements de données volumineux en masse ou des opérations de purge importantes pour réduire immédiatement la taille du fichier AOF.

Conclusion

Utilisez RDB lorsque vous voulez des sauvegardes compactes et pouvez tolérer la perte d'écritures récentes depuis le dernier instantané. Utilisez AOF lorsque Redis contient des données qui doivent survivre aux crashes avec une perte minimale. Pour les données de production importantes, activez AOF avec appendfsync everysec, conservez les instantanés RDB pour la sauvegarde, et testez le temps de restauration avant qu'une panne ne force la question.