Choisir la meilleure stratégie de persistance Redis : RDB contre AOF

Redis, un magasin de structures de données en mémoire, est réputé pour sa vitesse et sa polyvalence en tant que cache, magasin de sessions et courtier de messages. Bien que son fonctionnement principal soit en mémoire, assurer la durabilité et la récupérabilité des données est souvent crucial pour les déploiements en production. C'est là que la persistance Redis entre en jeu, permettant de sauvegarder l'état de votre ensemble de données sur disque.

Choisir la bonne stratégie de persistance est une décision critique qui équilibre l'intégrité des données, le temps de récupération et les implications en termes de performance. Redis offre deux mécanismes de persistance principaux : Redis Database Backup (RDB) et Append-Only File (AOF). Comprendre les nuances, les avantages et les compromis de chacun vous permettra de configurer Redis de manière optimale pour vos besoins spécifiques en matière de durabilité et de récupération des données.

Cet article explorera le RDB et l'AOF, en détaillant leur fonctionnement, leurs forces et faiblesses respectives, des exemples de configuration pratiques et comment les combiner pour une protection robuste des données. À la fin, vous serez équipé pour prendre une décision éclairée pour votre déploiement Redis.

Comprendre la persistance Redis

La persistance dans Redis fait référence à la capacité de sauvegarder l'ensemble de données en mémoire sur disque, afin qu'il puisse être rechargé après un redémarrage ou un crash du serveur. Sans persistance, toutes les données stockées dans Redis seraient perdues si le serveur s'arrête ou plante. Redis offre deux méthodes distinctes pour y parvenir :

RDB (Redis Database Backup) : Un instantané ponctuel de votre ensemble de données.
AOF (Append-Only File) : Un journal de chaque opération d'écriture effectuée par le serveur.

Les deux méthodes ont leurs propres caractéristiques et conviennent à différents scénarios.

Redis Database Backup (RDB)

La persistance RDB effectue des instantanés ponctuels de votre ensemble de données Redis à des intervalles spécifiés. Lorsqu'une opération de sauvegarde RDB est déclenchée, Redis fork un processus enfant. Le processus enfant écrit ensuite l'ensemble des données dans un fichier RDB temporaire. Une fois le fichier terminé, l'ancien fichier RDB est remplacé par le nouveau.

Comment fonctionne le RDB

Forking : Le serveur Redis fork un nouveau processus enfant.
Prise d'instantané : Le processus enfant commence à écrire l'ensemble des données dans un fichier RDB temporaire.
Achèvement : Une fois que le processus enfant a fini d'écrire, il remplace l'ancien fichier RDB par le nouveau fichier temporaire.
Nettoyage : Le processus enfant se termine.

Ce processus garantit que Redis peut continuer à servir les requêtes des clients pendant la prise de l'instantané, car le processus parent reste réactif.

Avantages du RDB

Sauvegardes compactes : Les fichiers RDB sont compressés binaire, offrant une représentation très compacte de votre ensemble de données Redis. Cela les rend idéaux pour les sauvegardes et la reprise après sinistre.
Redémarrages rapides : Le rechargement d'un fichier RDB est nettement plus rapide que la relecture d'un fichier AOF, en particulier pour les grands ensembles de données, car il s'agit de charger un seul fichier binaire pré-formaté.
E/S disque minimales : Les sauvegardes RDB ne se produisent qu'à des intervalles configurés, ce qui signifie que Redis effectue des E/S disque minimales lorsqu'il ne sauvegarde pas. Cela peut entraîner des performances plus élevées pendant les opérations normales.
Facile à transférer : Étant un fichier unique et compact, les sauvegardes RDB sont faciles à transférer vers des centres de données distants pour la reprise après sinistre ou à des fins d'archivage.

Inconvénients du RDB

Perte de données potentielle : Le principal inconvénient est la possibilité de perte de données. Si Redis tombe en panne entre les points de sauvegarde, toutes les données écrites depuis la dernière sauvegarde RDB réussie seront perdues.
Pic de performance pendant le fork : Pour les très grands ensembles de données, l'opération initiale de fork() peut être lente et bloquer le serveur Redis pendant une courte période, surtout si l'utilisation de la mémoire est élevée.
Persistance non en temps réel : RDB n'est pas conçu pour la persistance des données en temps réel. Il convient mieux aux scénarios où la perte de quelques minutes de données est acceptable.

Configuration RDB

La persistance RDB est activée par défaut dans redis.conf en utilisant la directive save. Vous pouvez spécifier plusieurs règles save :

# Sauvegarde la base de données toutes les 900 secondes (15 minutes) si au moins 1 clé a changé
save 900 1

# Sauvegarde la base de données toutes les 300 secondes (5 minutes) si au moins 10 clés ont changé
save 300 10

# Sauvegarde la base de données toutes les 60 secondes si au moins 10000 clés ont changé
save 60 10000

# Désactiver la persistance RDB (commentez toutes les directives save, ou définissez explicitement ci-dessous)
# save ""

Vous pouvez également déclencher une sauvegarde RDB manuellement en utilisant les commandes SAVE (bloquante) ou BGSAVE (non bloquante) dans redis-cli.

Append-Only File (AOF)

La persistance AOF enregistre chaque opération d'écriture reçue par le serveur Redis. Au lieu de sauvegarder l'ensemble des données périodiquement, AOF enregistre les commandes qui modifient l'ensemble de données. Lorsque Redis redémarre, il réexécute ces commandes du fichier AOF pour reconstruire l'ensemble de données original.

Comment fonctionne l'AOF

Enregistrement des commandes : Chaque commande d'écriture exécutée par Redis est ajoutée au fichier AOF.
Politique fsync : Redis propose diverses politiques fsync pour contrôler la fréquence de synchronisation du tampon AOF sur le disque :
- appendfsync always : Synchronise après chaque commande. Cela offre la meilleure durabilité mais est le plus lent.
- appendfsync everysec : Synchronise une fois par seconde. C'est un bon équilibre entre durabilité et performance (par défaut et recommandé).
- appendfsync no : S'appuie sur le système d'exploitation pour vider le tampon AOF sur le disque. Offre les meilleures performances mais la moindre durabilité.
Réécriture AOF : Au fil du temps, le fichier AOF peut devenir très volumineux en raison de commandes redondantes (par exemple, la mise à jour de la même clé plusieurs fois). La réécriture AOF optimise le fichier AOF en créant un nouveau fichier AOF plus petit contenant uniquement les commandes nécessaires pour reconstruire l'ensemble de données actuel. Ce processus est similaire au mécanisme de forking de RDB.

Avantages de l'AOF

Meilleure durabilité : Avec appendfsync always ou everysec, AOF offre une durabilité des données supérieure à RDB. Vous pouvez perdre au maximum une seconde de données (avec everysec) ou aucune donnée (avec always).
Moins de perte de données : En cas de crash, vous perdez significativement moins de données, voire aucune, selon votre politique fsync.
Lisible par l'homme : Les fichiers AOF sont lisibles par l'homme, ce qui facilite la compréhension de l'historique des opérations. Cela peut être utile pour le débogage ou la récupération de données dans des scénarios spécifiques.

Inconvénients de l'AOF

Taille de fichier plus importante : Les fichiers AOF sont généralement beaucoup plus volumineux que les fichiers RDB pour le même ensemble de données car ils stockent des commandes plutôt que des données compactes.
Récupération plus lente : La relecture d'un grand fichier AOF au démarrage peut être plus lente que le chargement d'un fichier RDB, car Redis doit exécuter chaque commande.
Impact sur les performances : Selon la politique fsync, AOF peut introduire plus d'E/S disque, ce qui peut avoir un impact sur les performances d'écriture. appendfsync always est particulièrement impactant.
Surcharge de la réécriture AOF : Bien que la réécriture AOF aide à gérer la taille des fichiers, le processus de réécriture lui-même consomme des ressources CPU et I/O et peut momentanément bloquer Redis si l'ensemble de données est très volumineux, de manière similaire au forking RDB.

Configuration AOF

Pour activer l'AOF, vous devez définir appendonly yes dans votre redis.conf :

# Activer la persistance AOF
appendonly yes

# Le nom du fichier append-only (par défaut : "appendonly.aof")
appendfilename "appendonly.aof"

# Options appendfsync : always, everysec, no
appendfsync everysec

# Réécriture automatique du fichier AOF lorsqu'il est deux fois plus grand que la base et fait au moins 64 Mo
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

RDB contre AOF : un aperçu comparatif

Caractéristique	RDB (Redis Database Backup)	AOF (Append-Only File)
Mécanisme	Instantanés ponctuels (fichier binaire)	Journal de toutes les opérations d'écriture (commandes textuelles)
Perte de données	Potentiel de perte de données entre les points de sauvegarde (minutes)	Perte de données minimale (secondes avec `everysec`, aucune avec `always`)
Performance	Performances d'écriture plus élevées pendant les opérations normales, blocage potentiel lors du `fork()`	Écritures plus lentes avec `fsync` fort, E/S plus cohérentes
Taille de fichier	Fichiers binaires très compacts	Généralement plus volumineux, croît avec les opérations
Temps de récupération	Plus rapide pour les grands ensembles de données	Plus lent pour les grands ensembles de données (relecture de commandes)
Facilité de sauvegarde	Fichier unique et compact ; facile pour les sauvegardes/la reprise après sinistre	Fichier plus volumineux, potentiellement plus difficile à gérer sans réécriture
Lisibilité	Non lisible par l'homme	Lisible par l'homme (commandes)
Par défaut dans Redis	Oui (avec les directives `save`)	Non (`appendonly no` par défaut)

L'approche hybride : RDB et AOF ensemble (Redis 4.0+)

Depuis Redis 4.0, il est possible et souvent recommandé de combiner la persistance RDB et AOF. Lorsque les deux sont activés, Redis utilisera principalement le fichier AOF pour reconstruire l'ensemble de données au démarrage, car il garantit une meilleure durabilité. Cependant, le processus de réécriture AOF dans Redis 4.0+ crée également un fichier AOF hybride qui commence par un préambule RDB, puis ajoute des commandes AOF. Cela combine le meilleur des deux mondes :

Réécritures plus rapides : La partie RDB de l'AOF hybride fournit un instantané initial beaucoup plus rapide pour le processus de réécriture.
Redémarrages plus rapides (potentiellement) : Lorsque Redis redémarre, il charge d'abord la partie RDB du fichier AOF, ce qui est plus rapide, puis rejoue les commandes AOF suivantes.
Meilleure durabilité : Bénéficie toujours de la perte de données minimale de l'AOF.

Pour activer ce mode hybride, il suffit d'avoir appendonly yes et vos directives save RDB configurées.

Choisir la bonne stratégie de persistance

La stratégie de persistance idéale dépend des exigences spécifiques de votre application en matière de durabilité des données, de performance et de temps de récupération.

1. Quand utiliser le RDB uniquement

Cas d'utilisation principal : Cache / Données non critiques : Si Redis est principalement utilisé comme cache où la perte de certaines données en cas de crash est acceptable, ou si vos données peuvent être facilement reconstruites à partir d'une autre source.
Exigences de haute performance : Lorsque les performances d'écriture sont primordiales et qu'une perte de données occasionnelle est tolérable.
Sauvegardes de reprise après sinistre : Les fichiers RDB sont excellents pour créer des instantanés périodiques pour l'archivage à long terme ou la reprise après sinistre. Vous pouvez cron un BGSAVE, puis déplacer le fichier .rdb hors site.
Efficacité de la mémoire : Si vous êtes fortement contraint par l'espace disque.

2. Quand utiliser l'AOF uniquement

Cas d'utilisation principal : Durabilité absolue : Lorsque chaque opération d'écriture est critique et que la perte de quelques secondes de données est inacceptable (par exemple, transactions financières, données utilisateur critiques). Dans ce cas, appendfsync always pourrait être envisagé, bien qu'avec un coût de performance significatif.
Débogage/Audit : La nature lisible par l'homme de l'AOF peut être bénéfique pour comprendre les modifications de données.

3. Quand utiliser à la fois RDB et AOF (recommandé pour la plupart des applications critiques)

Durabilité et récupération équilibrées : C'est généralement l'approche recommandée pour les systèmes de production où la durabilité des données est importante, mais où vous souhaitez également des redémarrages et des sauvegardes efficaces.
Robustesse : Fournit une couche de protection supplémentaire. Si une méthode de persistance est corrompue, vous pourrez peut-être toujours récupérer avec l'autre.
Redis 4.0+ : Tirez parti du format AOF à préambule RDB pour des réécritures AOF optimisées et des récupérations potentiellement plus rapides.

Conseils pratiques et bonnes pratiques

Surveiller l'utilisation du disque : RDB et AOF peuvent consommer un espace disque important. Surveillez l'utilisation de votre disque pour vous assurer de ne pas manquer d'espace, en particulier avant les réécritures AOF ou les sauvegardes RDB.
Politique fsync : Pour AOF, appendfsync everysec est le choix le plus courant et le plus recommandé, offrant un bon équilibre entre durabilité et performance. Évitez appendfsync no pour les données critiques.
Réécriture AOF : Configurez soigneusement auto-aof-rewrite-percentage et auto-aof-rewrite-min-size pour vous assurer que les fichiers AOF sont optimisés régulièrement sans consommation excessive de ressources.
Disques/Emplacements séparés : Si possible, stockez vos fichiers de persistance (AOF et RDB) sur un disque ou une partition différente de votre système d'exploitation et des journaux d'applications pour éviter les contentions d'E/S.
Sauvegardes externes : Indépendamment de votre stratégie de persistance, sauvegardez régulièrement vos fichiers RDB et AOF dans un emplacement hors site (par exemple, S3, Google Cloud Storage) pour une reprise après sinistre robuste.
Tester la récupération : Testez périodiquement votre processus de récupération avec la stratégie de persistance choisie pour vous assurer que les données peuvent être restaurées avec succès.

Conclusion

La persistance Redis est une pierre angulaire de la gestion fiable des données. RDB et AOF offrent tous deux des avantages et des compromis distincts. RDB fournit des instantanés compacts pour des redémarrages et des sauvegardes rapides, idéaux pour les données moins critiques ou l'archivage périodique. AOF offre une durabilité supérieure en enregistrant chaque commande, ce qui le rend adapté aux ensembles de données critiques où une perte de données minimale est primordiale.

Pour la plupart des environnements de production, l'utilisation conjointe de RDB et AOF (en particulier avec le format hybride de Redis 4.0+) offre la solution la plus robuste, offrant à la fois une récupération efficace et une forte durabilité des données. En évaluant soigneusement les exigences de votre application par rapport aux caractéristiques de chaque méthode de persistance, vous pouvez prendre une décision éclairée qui protège vos précieuses données et assure la résilience de votre déploiement Redis.