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

Redis stocke les données en mémoire, vous avez donc besoin d'une stratégie de persistance avant de vous y fier pour quoi que ce soit que vous ne pouvez pas reconstruire facilement. Le choix entre RDB et AOF affecte la quantité de données que vous pouvez perdre, la rapidité de redémarrage de Redis et la charge d'E/S disque que votre charge de travail génère.

Utilisez RDB lorsque des instantanés périodiques suffisent. Utilisez AOF lorsque vous avez besoin d'une durabilité plus stricte. Utilisez les deux lorsque vous souhaitez une durabilité pratique ainsi que des sauvegardes plus faciles, mais testez toujours la récupération avec votre jeu de données réel.

Comprendre la persistance Redis

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

RDB (Redis Database) : Un instantané ponctuel de votre jeu 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 sont adaptées à différents scénarios.

Redis Database (RDB)

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

Comment fonctionne RDB

Fork : Le serveur Redis crée un nouveau processus enfant.
Instantané : Le processus enfant commence à écrire l'intégralité du jeu de 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 à répondre aux demandes des clients pendant la prise de l'instantané, car le processus parent reste réactif.

Avantages de RDB

Sauvegardes compactes : Les fichiers RDB sont compressés en binaire, offrant une représentation très compacte de votre jeu 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 jeux de données, car il implique le chargement d'un seul fichier binaire pré-formaté.
E/S disque minimales : Les sauvegardes RDB se produisent uniquement à des intervalles configurés, ce qui signifie que Redis effectue un minimum d'E/S disque lorsqu'il ne sauvegarde pas. Cela peut entraîner des performances plus élevées lors des opérations normales.
Facile à transférer : Étant un seul fichier compact, les sauvegardes RDB sont faciles à transférer vers des centres de données distants pour la reprise après sinistre ou l'archivage.

Inconvénients de RDB

Perte de données potentielle : Le principal inconvénient est le risque de perte de données. Si Redis plante entre les points de sauvegarde, toutes les données écrites depuis la dernière sauvegarde RDB réussie seront perdues.
Pic de performance lors du fork : Pour les très grands jeux de données, l'opération initiale 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.
Pas une persistance en temps réel : RDB n'est pas conçu pour la persistance des données en temps réel. Il est mieux adapté 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 à l'aide de la directive save. Vous pouvez spécifier plusieurs règles save :

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

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

# Sauvegarder 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 à l'aide des 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'intégralité du jeu de données périodiquement, AOF enregistre les commandes qui modifient le jeu de données. Lorsque Redis redémarre, il réexécute ces commandes dans le fichier AOF pour reconstruire le jeu de données d'origine.

Comment fonctionne AOF

Journalisation des commandes : Chaque commande d'écriture exécutée par Redis est ajoutée au fichier AOF.
Politique fsync : Redis propose différentes 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 moins bonne durabilité.
Réécriture AOF : Avec le temps, le fichier AOF peut devenir très volumineux en raison de commandes redondantes (par exemple, mettre à jour 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 le jeu de données actuel. Ce processus est similaire au mécanisme de fork de RDB.

Avantages de AOF

Meilleure durabilité : Avec appendfsync always ou everysec, AOF offre une durabilité plus forte que les instantanés RDB périodiques. Avec everysec, Redis limite généralement la perte à environ une seconde d'écritures acquittées, bien que les pannes du système d'exploitation ou du disque puissent encore affecter la durabilité.
Moins de perte de données : En cas de crash, vous perdez beaucoup moins de données, voire aucune, selon votre politique fsync.
Format inspectable : AOF stocke les commandes du protocole Redis, il peut donc être inspecté et réparé avec les outils Redis plus facilement qu'un fichier RDB.

Inconvénients de AOF

Taille de fichier plus grande : Les fichiers AOF sont généralement beaucoup plus volumineux que les fichiers RDB pour le même jeu de données car ils stockent des commandes plutôt que des données compactes.
Récupération plus lente : La relecture d'un fichier AOF volumineux 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 potentiellement affecter les performances d'écriture. appendfsync always est particulièrement impactant.
Surcharge de réécriture AOF : Bien que la réécriture AOF aide à gérer la taille du fichier, le processus de réécriture lui-même consomme des ressources CPU et E/S et peut bloquer momentanément Redis si le jeu de données est très volumineux, similaire au fork RDB.

Configuration AOF

Pour activer 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 qu'il fait au moins 64 Mo
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

RDB vs. AOF : Un aperçu comparatif

Fonctionnalité	RDB (Sauvegarde de base de données Redis)	AOF (Fichier Append-Only)
Mécanisme	Instantanés ponctuels (fichier binaire)	Journal des opérations d'écriture au format du protocole Redis
Perte de données	Perte potentielle entre les points de sauvegarde	Généralement environ une seconde avec `everysec` ; plus forte avec `always`
Performance	Performances d'écriture plus élevées pendant les opérations normales, blocage potentiel sur `fork()`	Écritures plus lentes avec `fsync` fort, E/S plus cohérentes
Taille du fichier	Fichiers binaires très compacts	Généralement plus volumineux, augmente avec les opérations
Temps de récupération	Plus rapide pour les grands jeux de données	Plus lent pour les grands jeux de données (relecture des commandes)
Facilité de sauvegarde	Fichier unique et compact ; facile pour les sauvegardes/reprise après sinistre	Fichier plus volumineux, potentiellement plus difficile à gérer sans réécriture
Lisibilité	Non lisible par l'homme	Plus inspectable que RDB
Par défaut dans Redis	Oui (avec les directives `save`)	Non (`appendonly no` par défaut)

L'approche hybride : RDB et AOF ensemble

Redis peut utiliser les instantanés RDB et AOF ensemble. Lorsque AOF est activé, Redis utilise AOF pour la récupération au démarrage car il est généralement plus à jour. Redis moderne peut également utiliser un préambule RDB dans les fichiers AOF réécrits lorsque aof-use-rdb-preamble yes est activé, ce qui accélère les réécritures et les redémarrages.

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 d'AOF.

Vérifiez votre version de Redis et votre configuration avant de supposer que l'AOF hybride est activé.

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 performances et de temps de récupération.

1. Quand utiliser uniquement RDB

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 performances élevées : Lorsque les performances d'écriture sont primordiales et que la perte occasionnelle de données 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 planifier une BGSAVE avec cron, puis déplacer le fichier .rdb hors site.
Efficacité mémoire : Si vous êtes fortement contraint en espace disque.

2. Quand utiliser uniquement AOF

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 peut être envisagé, bien qu'avec un coût de performance significatif.
Débogage/Audit : La nature lisible par l'homme d'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.
AOF hybride : Tirez parti du format AOF avec préambule RDB là où il est pris en charge et activé.

Conseils pratiques et meilleures pratiques

Surveillez l'utilisation du disque : RDB et AOF peuvent consommer un espace disque important. Surveillez votre utilisation du 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 recommandé, offrant un bon équilibre entre durabilité et performances. Évitez appendfsync no pour les données critiques.
Réécriture AOF : Configurez auto-aof-rewrite-percentage et auto-aof-rewrite-min-size avec soin pour garantir 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érent de celui de votre système d'exploitation et des journaux d'application pour éviter la contention d'E/S.
Sauvegardes externes : Quelle que soit votre stratégie de persistance, sauvegardez régulièrement vos fichiers RDB et AOF vers un emplacement hors site (par exemple, S3, Google Cloud Storage) pour une reprise après sinistre robuste.
Testez la récupération : Testez périodiquement votre processus de récupération avec la stratégie de persistance que vous avez choisie pour garantir que les données peuvent être restaurées avec succès.

À retenir

Choisissez la persistance en fonction des exigences de récupération, pas par habitude. Un Redis utilisé uniquement comme cache peut souvent utiliser RDB ou aucune persistance. Un Redis utilisé pour les sessions, les files d'attente ou l'état de l'application a généralement besoin d'AOF, de sauvegardes testées et d'un exercice de redémarrage qui prouve que les données reviennent assez rapidement.