Meilleures pratiques pour prévenir la perte de données : Configuration RDB vs. AOF

Bonnes pratiques pour prévenir la perte de données : Configuration RDB vs. AOF dans Redis

Redis, un populaire magasin de structures de données en mémoire, offre des mécanismes de persistance robustes pour protéger vos données contre les défaillances. Comprendre et configurer correctement ces mécanismes – les instantanés RDB (Redis Database) et la journalisation AOF (Append-Only File) – est crucial pour minimiser la perte de données et assurer une récupération rapide. Cet article explore les nuances de RDB et AOF, vous guidant à travers les bonnes pratiques pour construire un déploiement Redis résilient.

Choisir la bonne stratégie de persistance, ou une combinaison des deux, a un impact direct sur la durabilité de vos données, le temps de récupération et les performances du système. Tandis que RDB fournit des instantanés à un moment précis, AOF enregistre chaque opération d'écriture. Chacun a ses forces et ses faiblesses, et la configuration optimale dépend souvent de la tolérance de votre application spécifique à la perte de données et de ses exigences de performance.

Comprendre les mécanismes de persistance de Redis

Redis propose deux méthodes principales pour la persistance des données sur disque, vous permettant de récupérer votre jeu de données après un redémarrage ou un crash du serveur :

1. Instantanés RDB (Redis Database)

RDB est un instantané à un moment précis de votre jeu de données Redis. Il fonctionne en créant un processus enfant (fork) du processus Redis principal, puis en demandant au processus enfant d'écrire l'intégralité du jeu de données dans un fichier dump.rdb. Ce processus est efficace pour les sauvegardes et la reprise après sinistre.

Fonctionnement de RDB :

Forking (Duplication de processus) : Redis utilise l'appel système fork() pour créer un processus enfant. Le processus parent continue de gérer les requêtes des clients tandis que le processus enfant accède à l'état de la mémoire au moment du fork.
Sérialisation : Le processus enfant sérialise l'intégralité du jeu de données dans un format binaire compact.
Sauvegarde sur disque : Les données sérialisées sont écrites dans un fichier spécifié (par défaut : dump.rdb).

**Configuration RDB (redis.conf):

# Sauvegarder la base de données si le plus grand nombre de secondes ET le plus grand nombre de clés
# modifiées sont au moins égaux aux valeurs spécifiées.
# format: save <secondes> <modifications>
save 900 1       # Sauvegarde après 15 minutes si au moins 1 clé a été modifiée
save 300 10      # Sauvegarde après 5 minutes si au moins 10 clés ont été modifiées
save 60 10000    # Sauvegarde après 1 minute si au moins 10000 clés ont été modifiées

# Le nom du fichier d'instantané (dump).
dbfilename dump.rdb

# Le répertoire où sauvegarder les fichiers RDB.
dir /var/lib/redis

Avantages de RDB :

Taille de fichier compacte : Les fichiers RDB sont généralement plus petits que les fichiers AOF, ce qui les rend plus rapides à transférer et à charger.
Redémarrages plus rapides : Le chargement d'un seul fichier RDB est plus rapide pour les grands jeux de données que la relecture d'un journal AOF.
Stratégie de sauvegarde simplifiée : Les instantanés RDB sont idéaux pour créer des sauvegardes à un moment précis.

Inconvénients de RDB :

Potentiel de perte de données : Si Redis tombe en panne entre les sauvegardes, toute donnée écrite après le dernier instantané sera perdue. La fréquence des sauvegardes dicte la fenêtre de perte de données potentielle.

2. Fichier journal en ajout seulement (AOF)

AOF journalise chaque opération d'écriture reçue par le serveur Redis. Lorsque Redis redémarre, il réexécute les commandes contenues dans le fichier AOF pour reconstruire le jeu de données. Cela offre une durabilité bien supérieure à RDB.

Fonctionnement de AOF :

Journalisation des commandes : Chaque commande d'écriture est ajoutée (append) à un fichier AOF.
Mode d'ajout : Le fichier est écrit en mode ajout seulement (append-only).
Politique fsync : Vous pouvez configurer la fréquence à laquelle Redis vide le tampon AOF sur le disque (fsync). C'est crucial pour la durabilité.

**AOF Configuration (redis.conf):

# Activer le mode Append Only (Ajout seulement).
aof yes

# Le nom du fichier AOF.
aof-rewrite-incremental-fsync yes

# Les modes de réécriture suivants ne sont pas pris en charge si vous activez AOF
# La persistance AOF repose sur appendfsync (). Les options sont :
# no : Ne jamais fsync, laisser simplement le système d'exploitation vider le tampon de données. Plus rapide mais les données
#     seront perdues en cas de crash.
# everysec : fsync () chaque seconde. La latence moyenne est d'environ 30 ms, mais certaines
#           données seront perdues en cas de crash.
# always : fsync () chaque fois qu'une opération d'écriture est effectuée. Plus sûr mais pas
#         aussi rapide.
appendfsync everysec

# Réécrire automatiquement le fichier AOF lorsqu'il devient trop volumineux.
aof-auto-rewrite-percentage 100
aof-auto-rewrite-min-size 64mb

Avantages de AOF :

Haute durabilité : Avec appendfsync always ou appendfsync everysec, AOF réduit considérablement le risque de perte de données.
Reconstruction : Redis peut reconstruire le jeu de données en rejouant les commandes.

Inconvénients de AOF :

Taille de fichier plus grande : Les fichiers AOF peuvent devenir très volumineux au fil du temps car ils journalisent chaque opération.
Redémarrages plus lents : La relecture d'un grand fichier AOF peut prendre plus de temps que le chargement d'un instantané RDB.
Réécriture AOF : Redis réécrit périodiquement le fichier AOF sous une forme plus compacte pour gérer sa taille. Ce processus peut consommer des ressources.

Bonnes pratiques pour la prévention de la perte de données

Pour prévenir efficacement la perte de données, considérez les bonnes pratiques suivantes :

1. Utiliser à la fois RDB et AOF (Recommandé)

L'approche la plus robuste consiste à activer la persistance RDB et AOF. Cela combine les avantages des deux méthodes :

RDB pour les sauvegardes : Fournit une sauvegarde pratique à un moment précis pour la reprise après sinistre et les redémarrages rapides.
AOF pour la durabilité : Garantit que même si Redis tombe en panne entre les instantanés RDB, vous ne perdez qu'une quantité minimale de données (selon le paramètre appendfsync).

**Exemple de configuration (redis.conf):

# Activer la persistance RDB
save 900 1
save 300 10
save 60 10000

# Activer la persistance AOF
aof yes
appendfsync everysec

Pourquoi c'est une bonne pratique : Si votre serveur tombe en panne, Redis tentera d'abord de charger le fichier RDB. Si le fichier RDB est corrompu ou manquant, il se rabattra sur le fichier AOF. Le paramètre appendfsync everysec offre un bon équilibre entre performance et durabilité, garantissant que vous ne perdez au maximum qu'une seconde de données dans le pire des cas.

2. Choisir la bonne politique `appendfsync`

C'est le paramètre le plus critique pour la durabilité AOF. Votre choix dépend de la tolérance de votre application à la perte de données :

appendfsync no : Performance la plus élevée, mais risque de perte de données le plus élevé (toutes les écritures depuis le dernier vidage du système d'exploitation).
appendfsync everysec : Recommandé pour la plupart des cas d'utilisation. Offre de bonnes performances avec une perte de données minimale (au maximum 1 seconde).
appendfsync always : Durabilité la plus élevée, mais peut avoir un impact significatif sur les performances d'écriture en raison des synchronisations fréquentes sur disque.

Recommandation : Commencez avec appendfsync everysec. Surveillez vos performances d'écriture et votre tolérance à la perte de données pour déterminer si appendfsync always est nécessaire ou si no est acceptable pour des données moins critiques.

3. Configurer judicieusement les points de sauvegarde RDB

Pour RDB, choisissez des points de sauvegarde qui correspondent à votre fenêtre de perte de données acceptable. Les sauvegardes fréquentes réduisent la perte de données mais augmentent la charge CPU.

Exemple : Si perdre 5 minutes de données est inacceptable, assurez-vous d'avoir un point de sauvegarde qui se déclenche dans ce laps de temps, par exemple, save 300 10.
Équilibre : Évitez les points de sauvegarde excessivement agressifs (par exemple, save 10 100) sauf si c'est absolument nécessaire, car ils peuvent impacter la réactivité de Redis.

4. Gérer efficacement la réécriture AOF

La réécriture AOF est essentielle pour maintenir la taille du fichier AOF gérable. Configurez auto-rewrite-percentage et auto-rewrite-min-size pour déclencher les réécritures lorsque le fichier augmente de manière significative.

Par défaut : aof-auto-rewrite-percentage 100 signifie une réécriture lorsque le fichier AOF atteint deux fois la taille de la dernière réécriture. aof-auto-rewrite-min-size 64mb garantit que les réécritures ne se produisent pas trop souvent sur des fichiers plus petits.
Surveillance : Gardez un œil sur la taille du fichier AOF. S'il augmente excessivement, envisagez d'ajuster ces paramètres ou de déclencher une réécriture manuelle à l'aide de BGREWRITEAOF.

5. Mettre en œuvre des sauvegardes régulières des fichiers de persistance

Même avec la persistance activée, il est prudent de sauvegarder vos fichiers dump.rdb et AOF dans un emplacement distinct. Cela protège contre les pannes matérielles, les suppressions accidentelles ou même la corruption du stockage de l'instance Redis entière.

Stratégie : Utilisez des outils ou des scripts externes pour copier ces fichiers périodiquement vers un stockage réseau ou des buckets cloud.

6. Surveiller la santé de Redis et les I/O disque

La surveillance proactive est essentielle pour prévenir la perte de données. Portez attention à :

Journaux Redis : Recherchez les avertissements liés à la persistance, les erreurs de disque plein ou les écritures lentes.
Métriques système : Surveillez les E/S disque (en particulier la latence et le débit d'écriture), l'utilisation du CPU et la consommation de mémoire.
Commande Redis INFO persistence : Cette commande fournit des informations précieuses sur l'état de RDB et AOF, y compris les heures de dernière sauvegarde et l'état de la réécriture AOF.

7. Envisager Redis Sentinel ou Cluster pour la haute disponibilité

Bien qu'ils ne soient pas strictement des configurations de persistance, Redis Sentinel et Redis Cluster offrent une haute disponibilité en basculant automatiquement vers une réplique si le nœud maître devient indisponible. Cela réduit considérablement les temps d'arrêt et, par extension, la fenêtre de perte potentielle de données si les mécanismes de persistance sont également en place.

Conclusion

La prévention de la perte de données dans Redis est un aspect essentiel du maintien d'une application fiable. En comprenant les forces et les faiblesses de la persistance RDB et AOF, et en mettant en œuvre les bonnes pratiques telles que l'utilisation des deux mécanismes, le choix judicieux des politiques appendfsync et la gestion des réécritures AOF, vous pouvez améliorer considérablement la durabilité de votre déploiement Redis. Compléter ces paramètres par des sauvegardes régulières et une surveillance proactive fournira une défense robuste contre la perte de données et assurera la continuité des activités.