[Redis] Compréhension approfondie du mécanisme de persistance Redis - RDB et AOF

Annuaire d'articles

1. Persistance Redis
2. Mécanisme de persistance RDB
3. Mécanisme de persistance AOF
4. Persistance mitigée

1. Persistance Redis

Bien que Redis soit une base de données en mémoire, les données en mémoire peuvent être perdues pour diverses raisons, telles que le redémarrage du serveur Redis, un crash inattendu, etc. Afin de garantir la persistance et la fiabilité des données, Redis introduit un mécanisme de persistance, qui permet de sauvegarder régulièrement les données sur le disque afin que les données d'origine puissent être restaurées en mémoire au prochain démarrage de Redis.

Le mécanisme de persistance de Redis est une partie importante de la base de données Redis, qui permet d'écrire les données en mémoire sur le disque de différentes manières pour éviter toute perte de données. Ceci est essentiel pour de nombreux scénarios d'application, en particulier pour les systèmes qui doivent conserver les données pendant une longue période ou qui ont des exigences de haute disponibilité.

Dans cet article, nous aborderons les deux principaux mécanismes de persistance de Redis, à savoir RDB (Redis DataBase) et AOF (Append-Only File), ainsi que leur fonctionnement, leurs avantages et inconvénients, et comment les configurer. De plus, vous serez initié au concept de persistance hybride, qui est un moyen de combiner RDB et AOF pour profiter pleinement de leurs avantages respectifs. En lisant cet article, j'espère qu'il pourra aider les lecteurs à mieux comprendre le mécanisme de persistance Redis afin qu'ils puissent être correctement configurés et gérés en fonction des exigences réelles de l'application.

2. Mécanisme de persistance RDB

2.1 Compréhension du RBD

Concept RDB

RDB (Redis DataBase) est une méthode de persistance de Redis. Elle est utilisée pour enregistrer les données actuelles en mémoire dans un fichier instantané sur le disque dur . Ce fichier instantané contient toutes les données à un moment précis, y compris les paires clé-valeur, les structures de données, etc. RDB fonctionne comme une sauvegarde d'une base de données en enregistrant périodiquement les données en mémoire dans un fichier persistant pour la récupération des données en cas de besoin.

Avantages et inconvénients du mécanisme de persistance RDB

avantage:

Hautes performances : le mécanisme de persistance RDB fonctionne bien en termes de performances. Étant donné que RDB est forkréalisé via un processus enfant, le processus principal n'a pas besoin d'effectuer d'opérations d'E/S lourdes , ce qui garantit que Redis maintient un débit élevé lors de la génération d'instantanés RDB.
Compacts et lisibles : les fichiers RDB sont dans un format binaire efficace qui contient bien les données et est très compact. Cela permet aux fichiers RDB d'économiser de l'espace disque et d'être hautement lisibles, ce qui facilite la sauvegarde et la migration .
Adaptés à la reprise après sinistre : les fichiers RDB sont des instantanés complets de base de données qui peuvent être utilisés pour récupérer des données après un sinistre, tel qu'une panne de disque dur ou une corruption irréversible des données.
Sauvegarde et migration : en raison de la compacité et de la lisibilité des fichiers RDB, il est idéal pour sauvegarder des données ou migrer des données Redis entre différents environnements.
Économiser de l'espace disque : vous pouvez configurer la fréquence d'enregistrement de RDB selon vos besoins, contrôlant ainsi l'utilisation de l'espace disque dans une certaine mesure.

défaut:

Des données peuvent être perdues : RDB est un fichier d'instantané généré régulièrement. Si le serveur Redis plante entre les instantanés, les données après le dernier instantané peuvent être perdues.
Ne convient pas aux données à grande échelle : lors du traitement de données à grande échelle, la génération de fichiers RDB peut provoquer un blocage à long terme et affecter les performances. Dans certains cas, les délais de blocage peuvent devenir inacceptables.
Ne convient pas aux besoins de persistance en temps réel : RDB est basé sur des instantanés et ne peut donc pas fournir de persistance en temps réel. Si vous avez besoin que chaque opération d'écriture soit conservée immédiatement sur le disque, RDB n'est peut-être pas le meilleur choix.
Modification du fichier de configuration : si le fichier de configuration Redis est modifié fréquemment, RDB peut devenir inapproprié car il ne générera des instantanés que lorsque le serveur Redis est arrêté normalement. Cela peut entraîner une perte de données après des modifications de configuration.

En résumé, le mécanisme de persistance RDB fonctionne bien en termes de performances, de sauvegarde et de compacité et convient à de nombreux scénarios d'utilisation, mais il convient de noter que des données peuvent être perdues et doivent être soigneusement prises en compte lors de la gestion de données à grande échelle. Si vous avez des exigences plus élevées en matière de persistance en temps réel, vous pouvez envisager d'utiliser le mécanisme de persistance AOF ou la persistance hybride pour compenser les lacunes de RDB.

Configuration liée au RDB

La persistance RDB de Redis peut être configurée dans le fichier de configuration Redis (généralement redis.conf). Voici quelques éléments de configuration courants liés à la persistance RDB :

À quelle fréquence enregistrer les instantanés :

save 900 1        # 表示在900秒（15分钟）内，如果至少有1个键发生变化，就会触发RDB快照保存。
save 300 10       # 表示在300秒（5分钟）内，如果至少有10个键发生变化，就会触发RDB快照保存。
save 60 10000     # 表示在60秒内，如果至少有10000个键发生变化，就会触发RDB快照保存。

Ces éléments de configuration définissent les conditions de déclenchement de la persistance RDB. Selon les exigences spécifiques de l'application, les instantanés RDB peuvent être déclenchés en fonction de différents intervalles de temps et du nombre de modifications clés.

Nom et chemin du fichier RDB :
```
dbfilename dump.rdb    # 指定RDB快照文件的名称
dir /var/lib/redis     # 指定RDB文件的保存路径
```
Ces éléments de configuration vous permettent de spécifier le nom et le chemin d'enregistrement du fichier d'instantané RDB. Notez que vous devez vous assurer que le dossier existe et dispose des autorisations appropriées.
Désactivez la persistance automatique RDB :
```
save ""              # 禁用自动RDB持久化
```
Si vous souhaitez désactiver la persistance RDB déclenchée automatiquement, vous pouvez savedéfinir l'élément de configuration sur une chaîne vide.
Compression persistante RDB :
```
rdbcompression yes  # 开启 RDB 文件压缩（默认情况下是开启的）
```
Cet élément de configuration contrôle s'il faut compresser le fichier RDB généré. Son activation peut réduire la taille du fichier RDB, mais il occupera des ressources CPU supplémentaires.
Fichier de point de contrôle :
```
rdbchecksum yes     # 在保存RDB文件时是否进行校验和检查（默认情况下是开启的）
```
Cet élément de configuration contrôle s'il faut effectuer des vérifications de somme de contrôle lors de l'enregistrement des fichiers RDB pour garantir l'intégrité des fichiers.

Veuillez noter que pour que les modifications de configuration prennent effet, le serveur Redis doit être redémarré. En fonction des besoins de l'application et du volume de données, ces éléments de configuration peuvent être ajustés pour répondre aux exigences de performances et de durabilité.

2.2 Synchronisation de déclenchement du RDB

Le moment de déclenchement du RDB est divisé en deux manières : déclenchement automatique et déclenchement manuel :

Déclenchement automatique

Le déclenchement automatique est obtenu grâce à la fréquence d'enregistrement des instantanés dans le fichier de configuration. Dans le fichier de configuration Redis (redis.conf), vous pouvez définir une ou plusieurs savedirectives pour définir quand déclencher automatiquement l'enregistrement des instantanés RDB. Chaque savecommande a deux paramètres, le premier paramètre est l'intervalle de temps en secondes et le deuxième paramètre est le nombre de touches modifiées.

Par exemple, voici un exemple de configuration déclenchée automatiquement pour enregistrer un instantané :

save 900 1        # 表示在900秒（15分钟）内，如果至少有1个键发生变化，就会触发RDB快照保存。
save 300 10       # 表示在300秒（5分钟）内，如果至少有10个键发生变化，就会触发RDB快照保存。
save 60 10000     # 表示在60秒内，如果至少有10000个键发生变化，就会触发RDB快照保存。

Ces éléments de configuration définissent les conditions dans lesquelles RDB déclenche automatiquement l'enregistrement des instantanés. Redis vérifiera régulièrement ces conditions, et si l'une d'entre elles est remplie, cela déclenchera la génération d'un instantané RDB.

Bien entendu, s'il est configuré save "", le déclenchement automatique sera désactivé.

Déclenchement manuel : SAVE et BGSAVE

Le déclenchement manuel des instantanés RDB est réalisé via les commandes Redis. Deux commandes principales sont disponibles :

Commande SAVE : utilisez la commande SAVE pour générer immédiatement un instantané RDB, qui s'exécutera sur 阻塞le serveur Redis jusqu'à ce que la génération de l'instantané RDB soit terminée. 这个命令不常用，因为它会导致 Redis 服务器在生成快照期间停止响应其他请求.

grammaire:

SAVE

Commande BGSAVE : utilisez la commande BGSAVE pour générer des instantanés RDB en arrière-plan sans bloquer le fonctionnement normal du serveur Redis. Il s'agit de la méthode de déclenchement manuel généralement recommandée.

BGSAVE

La commande BGSAVE utilise les appels système fournis par le système d'exploitation forkpour démarrer un processus enfant chargé de générer les fichiers d'instantanés RDB, tandis que le processus principal continue de répondre aux autres requêtes. Une fois la génération terminée, BGSAVE enregistre le fichier RDB sur le disque puis en informe le processus principal.

Le processus de fonctionnement de la commande BGSAVE :

illustrer:

Lors de l'exécution de la commande BGSAVE,le processus parent Redis déterminera d'abord s'il existe d'autres processus enfants en cours d'exécution, tels que des processus enfants exécutant des commandes liées à RDB ou AOF. S'il y en a, la commande BGSAVE à ce moment reviendra directement.

Le processus parent s'exécutera pour forkcréer le processus enfant, et le processus parent sera bloqué pendant le processus de fork. Grâce à info statsl'option d'affichage des commandes latest_fork_usec, vous pouvez obtenir le temps nécessaire à la dernière forkopération, en microsecondes.

Une fois l'exécution du processus parent forkterminée, la commande BGSAVE renverra le message "Sauvegarde en arrière-plan démarrée". Après cela, le processus parent ne sera plus bloqué et pourra continuer à répondre à d'autres commandes. Dans le même temps, le processus enfant est responsable de la génération des fichiers instantanés RDB.

Lorsque le processus enfant crée un fichier RDB, il générera un fichier instantané temporaire basé sur la mémoire du processus parent. Une fois terminé, le dump.rdbfichier d'origine sera remplacé atomiquement. L'exécution lastsavede la commande peut obtenir l'heure de la dernière génération du RDB, correspondant à l' option infostatistique .rdb_last_save_time

Une fois que le processus enfant a terminé la création du fichier RDB, il enverra un signal au processus parent pour indiquer l'achèvement, et le processus parent mettra à jour les statistiques.

Les instantanés RDB déclenchés manuellement sont généralement utilisés pour sauvegarder les données Redis, gérer manuellement les stratégies de persistance ou créer des instantanés cohérents de données avant d'effectuer certaines opérations. En bref, le timing de déclenchement de RDB peut être obtenu de deux manières : le déclenchement automatique et le déclenchement manuel, en fonction des exigences spécifiques de l'application et des stratégies de gestion. Le déclenchement automatique est un mécanisme de sauvegarde périodique, tandis que le déclenchement manuel vous permet de créer des instantanés RDB immédiatement en cas de besoin.

2.3 Traitement des fichiers RDB

Le fichier RDB est un fichier instantané de la base de données Redis, qui enregistre les données actuelles en mémoire afin qu'elles puissent être restaurées en cas de besoin. Voici des informations importantes sur la manipulation et la gestion des fichiers RDB :

Enregistrer le fichier RDB

Chemin d'enregistrement du fichier : les fichiers RDB sont enregistrés par défaut dans le répertoire spécifié dans le fichier de configuration Redis /var/lib/redis/. Le nom du fichier est spécifié par les paramètres du fichier de configuration dbfilenameet est par défaut "dump.rdb". CONFIG SETVous pouvez utiliser la commande pour modifier dynamiquement le répertoire d'enregistrement et le nom du fichier pendant l'exécution de Redis , par exemple :
```
CONFIG SET dir /new/directory/
CONFIG SET dbfilename newdump.rdb
```
Cela enregistrera le fichier RDB dans un nouveau répertoire et utilisera un nouveau nom de fichier.
Sauvegarde manuelle : La sauvegarde du fichier RDB peut être déclenchée manuellement par l'exécution SAVEd' une commande. La commande bloquera les autres requêtes pendant que le serveur Redis génère le fichier RDB, tandis que la commande générera le fichier RDB en arrière-plan sans bloquer les autres opérations.BGSAVESAVEBGSAVE
```
  SAVE
BGSAVE
```

Compresser les fichiers RDB

Redis utilise l'algorithme LZF par défaut pour compresser les fichiers RDB générés afin de réduire la taille du fichier et d'économiser de l'espace disque et de la bande passante réseau. La compression est activée par défaut, mais on peut la modifier dynamiquement avec la commande suivante :

CONFIG SET rdbcompression yes   # 开启RDB文件压缩
CONFIG SET rdbcompression no    # 禁用RDB文件压缩

Bien que la compression des fichiers RDB consomme des ressources CPU, il est généralement recommandé de l'activer, en particulier lorsque l'espace disque et la bande passante du réseau sont limités, car cela peut réduire considérablement la taille du fichier.

Vérifier le fichier RDB

Redis chargera le fichier RDB au démarrage. Si le fichier est endommagé ou a un format incorrect, Redis refusera de démarrer. Afin de vérifier l'intégrité et la validité des fichiers RDB, vous pouvez utiliser les outils fournis par Redis redis-check-rdb. Cet outil détectera les fichiers RDB et générera des rapports d'erreurs correspondants pour nous aider à identifier et à résoudre les problèmes.

Vérifiez le fichier RDB :

Le traitement et la gestion des fichiers RDB sont une tâche importante pour garantir la durabilité et la fiabilité des données Redis. Comprendre comment enregistrer, compresser et vérifier les fichiers RDB peut nous aider à mieux gérer les bases de données Redis.

3. Mécanisme de persistance AOF

3.1 Comprendre l'AOF

Le concept de l'AOF

AOF (Append-Only File) est un mécanisme de persistance de Redis, utilisé pour 写操作以追加的方式记录到一个文本文件中implémenter la persistance des données sur le serveur Redis. Chaque opération d'écriture est ajoutée à la fin du fichier AOF sous la forme d'une commande Redis. Le fichier AOF est donc un fichier journal qui enregistre les opérations d'écriture par ordre chronologique.

Avantages et inconvénients de l'AOF

avantage:

Sécurité des données : AOF enregistre chaque opération d'écriture, donc en cas de panne ou de crash du serveur, seules les données après la dernière opération d'écriture seront perdues. Cela offre une plus grande sécurité des données.
Lisibilité : Un fichier AOF est un fichier texte facile à lire et à comprendre pour les humains. Cela rend les fichiers AOF très utiles lorsque vous devez récupérer manuellement des données ou effectuer un débogage.
Flexibilité : Le mode d'écriture des fichiers AOF rend la persistance des données très temps réel. Différentes stratégies de synchronisation peuvent être sélectionnées en fonction des besoins, de totalement synchrone à asynchrone.
Réécriture automatique : Redis fournit un mécanisme de réécriture automatique pour les fichiers AOF, ce qui peut empêcher les fichiers AOF d'être trop volumineux et améliorer les performances.

défaut:

Taille du fichier : par rapport à la persistance RDB, les fichiers AOF sont généralement plus gros car ils contiennent le texte de commande pour chaque opération d'écriture. Cela peut prendre plus d'espace disque.
Performances d'écriture : la persistance AOF entraînera l'ajout de chaque opération d'écriture au fichier AOF, ce qui peut avoir un certain impact sur les performances d'écriture, notamment lors de l'utilisation d'une stratégie d'écriture synchrone.

Configuration liée à l'AOF

Dans Redis, vous pouvez CONFIGconfigurer les paramètres liés à la persistance AOF via le fichier de configuration ou à l'aide de la commande. Voici quelques options de configuration AOF couramment utilisées :

appendonly: Utilisé pour activer ou désactiver la persistance AOF. Réglez sur « oui » pour activer AOF et sur « non » pour le désactiver. Par défaut, la persistance AOF est désactivée et doit être activée manuellement.
appendfilename: Spécifiez le nom du fichier AOF, la valeur par défaut est "appendonly.aof". Vous pouvez modifier le nom du fichier selon vos besoins.
appendfsync: Spécifiez la stratégie de synchronisation des fichiers AOF sur le disque. Les options disponibles incluent « toujours » (synchroniser chaque écriture), « everysec » (synchroniser une fois par seconde) et « non » (entièrement asynchrone).
auto-aof-rewrite-percentageet auto-aof-rewrite-min-size: utilisé pour configurer les conditions de déclenchement de la réécriture automatique AOF. Le premier indique le pourcentage d'augmentation de la taille du fichier AOF par rapport à la taille de la dernière réécriture lorsque la réécriture est déclenchée, et le second indique la taille minimale du fichier AOF.

Ces options de configuration se trouvent dans le fichier de configuration de Redis (généralement redis.conf) ou peuvent CONFIGêtre définies dynamiquement via des commandes. En fonction de vos besoins et de vos scénarios d'application, la persistance AOF peut être configurée de manière flexible pour répondre aux exigences de persistance des données et de performances.

3.2 Utilisation de l'AOF

Utilisez la démo

Après avoir configuré les options liées à AOF, vous devez utiliser la commande service redis-server restartpour redémarrer le serveur Redis. Après le redémarrage, vous constaterez qu'il y dump.rdba un fichier supplémentaire dans le même répertoire que le fichierappendonly.aof :

Définissez deux éléments de données dans Redis :

Afficher appendonly.aofle fichier :

le contenu du fichier est la commande pour écrire des données à l'instant.

Terminez brusquement le serveur Redis puis redémarrez-le :

connectez-vous et interrogez la base de données Redis et constatez que les données ne sont pas perdues :

Flux de travail AOF

Le diagramme de flux de travail est le suivant :

Toutes les commandes d'écriture sont ajoutées au aof_buftampon.
Le tampon AOF effectue des opérations de synchronisation sur le disque dur selon la politique correspondante.
À mesure que les fichiers AOF deviennent de plus en plus volumineux, les fichiers AOF doivent être réécrits régulièrement pour obtenir une compression.
Lorsque le serveur Redis démarre, les commandes du fichier AOF sont chargées pour la récupération des données.

Écriture de commande :
le contenu écrit par la commande AOF suit directement le format de protocole texte de Redis. Par exemple, set hello worldla commande est représentée au format de protocole texte dans le tampon AOF comme suit :

*3\r\n$3\r\nset\r\n$5\r\nhello\r\n$5\r\nworld\r\n

Les raisons pour lesquelles Redis choisit le protocole texte incluent une bonne compatibilité, une mise en œuvre simple et une lisibilité.

Pourquoi utiliser aof_bufle tampon :

Le tampon AOF (aof_buf) existe pour améliorer les performances d'écriture. Étant donné que Redis répond aux commandes dans un seul thread, si chaque écriture est directement synchronisée sur le disque dur, les performances seront sérieusement affectées. En écrivant d'abord des commandes dans le tampon, Redis peut réduire efficacement le nombre d'opérations d'E/S et améliorer les performances. En outre, Redis propose également diverses stratégies de synchronisation des tampons, permettant aux utilisateurs de faire des compromis en fonction des exigences de performances et de sécurité des données.

3.3 Stratégie de fichier de synchronisation AOF

Redis fournit une variété de stratégies de fichiers de synchronisation de tampon AOF, qui sont contrôlées par redis.confdes paramètres dans le fichier de configuration ( ) appendfsync. Les valeurs configurables et leurs descriptions sont présentées dans le tableau suivant :

Valeurs configurables	illustrer
toujours	Chaque passage en `write`écriture `aof_buf`forcera un appel immédiat `fsync`pour synchroniser les données sur le disque, garantissant ainsi la sécurité des données, mais de mauvaises performances d'écriture.
chaque seconde	En `write`ajoutant d'abord à l'opération `aof_buf`, puis en effectuant une opération de synchronisation toutes les secondes, les données sont synchronisées dans le fichier AOF pour équilibrer les performances et la sécurité des données.
Non	Seules les opérations d'écriture sont `write`ajoutées par `aof_buf`, les opérations de synchronisation sont contrôlées par le système d'exploitation. Cette configuration offre les performances d'écriture les plus élevées mais une sécurité des données inférieure.

Notes sur les appels système writeet :fsync

writeL'opération a déclenché le mécanisme d'écriture différée. Le noyau Linux fournit des tampons de page pour améliorer les performances d'E/S du disque dur. writeL'opération revient immédiatement après l'écriture des données dans le tampon système. La synchronisation sur le disque repose sur le mécanisme de planification du système d'exploitation, par exemple lorsque la page tampon est pleine ou qu'un intervalle de temps spécifique est atteint. Si le système plante ou plante avant la synchronisation des fichiers, les données du tampon peuvent être perdues.
fsyncIl s'agit d'une opération pour un seul fichier. Elle effectue une synchronisation forcée du disque dur et fsyncse bloque jusqu'à ce que les données soient écrites sur le disque dur.

Différentes valeurs de configuration :

alwaysUne fois configuré , chaque écriture force la synchronisation du fichier AOF, ce qui entraîne de mauvaises performances. Sur un disque dur SATA général, il ne peut prendre en charge que quelques centaines d'écritures TPS. Il n'est généralement pas recommandé de configurer cela alwayssauf si les données sont très importantes.
noLorsque la configuration est incorrecte , puisque la politique de synchronisation du système d'exploitation n'est pas contrôlée, même si les performances sont améliorées, le risque de perte de données est considérablement augmenté. Il n'est généralement pas recommandé de configurer cela nosauf si l'importance des données est très faible.
Configuré sur everysecest la configuration par défaut et l'option de configuration recommandée, qui prend en compte la sécurité et les performances des données. En théorie, seulement 1 seconde de données sera perdue au maximum.

Ces options de configuration permettent aux utilisateurs de choisir une stratégie de synchronisation AOF appropriée en fonction des exigences de performances et de sécurité des données.

3.4 Mécanisme de réécriture AOF

Pourquoi réécrire les fichiers AOF

Le fichier AOF est réécrit pour résoudre le problème du grand nombre de commandes invalides pouvant exister dans Redis. Illustrons avec quelques exemples simples :

Dans Redis, la série de commandes d'écriture suivante est exécutée :

SET key1 123
SET key1 hello
SET key1 world
SET key1 123

Bien que 4 commandes d'écriture aient été exécutées ci-dessus, seules les données écrites par la dernière commande existent dans Redis, c'est-à-dire que la key1valeur est 123.

De même, la série de commandes d’écriture suivante a été exécutée :

SET key2 123
SET key2 hello
SET key2 world
SET key2 123
DEL key2

Bien que 5 commandes d’écriture aient été exécutées ci-dessus, elles key2n’existaient finalement pas dans Redis.

Par exemple, exécutez la commande suivante dans Redis :
Avant de réécrire :
Après réécriture :

À cette époque, il a été constaté que des caractères tronqués apparaissaient, c'est-à-dire qu'ils étaient stockés sous forme binaire. La raison en est que AOP et RDB étaient activés en même temps, donc la stratégie de persistance adoptée par Redis à cette époque était hybride persistance.

Utilisez l'outil de vérification fourni par Redis redis-check-aofpour vérifier le fichier AOF et vous constaterez que le fichier AOF est légal :

On peut conclure des deux exemples simples ci-dessus :

Sans le mécanisme de réécriture de fichier AOF, Redis continuera à stocker un grand nombre de commandes invalides, ce qui entraînera une augmentation de la taille du fichier AOF, occupera beaucoup d'espace disque et réduira les performances de lecture du fichier AOF.
La réécriture du fichier AOF résout ce problème en nettoyant ces commandes invalides et en générant un nouveau fichier AOF plus compact et efficace. Le nouveau fichier AOF contient uniquement des commandes d'écriture valides, ce qui permet de réduire la taille du fichier, d'améliorer les performances de lecture et de garantir qu'aucune donnée valide n'est perdue. C'est la raison pour laquelle les fichiers AOF doivent être réécrits.

Comment déclencher la réécriture AOF

La réécriture des fichiers AOF peut être déclenchée des deux manières suivantes :

Déclenchement manuel : En appelant la commande fournie par Redis BGREWRITEAOF, le processus de réécriture du fichier AOF peut être déclenché manuellement. Cette commande commencera immédiatement à réécrire le fichier AOF sans affecter le fonctionnement normal de Redis.
Déclenchement automatique : Redis prend également en charge le déclenchement automatique de la réécriture des fichiers AOF. Le timing de déclenchement est déterminé en fonction de deux paramètres de configuration :
- auto-aof-rewrite-min-size: Ce paramètre définit la taille minimale du fichier AOF, en Mo. La valeur par défaut est 64 Mo. Ce n'est que lorsque la taille du fichier AOF dépasse ce seuil que la réécriture automatique sera envisagée.
- auto-aof-rewrite-percentage: Ce paramètre définit le taux de croissance de la taille du fichier AOF par rapport à la dernière réécriture, exprimé en pourcentage. La valeur par défaut est 100 %. Si la taille du fichier AOF dépasse ce pourcentage depuis la dernière réécriture, une réécriture automatique sera déclenchée.
Par exemple, si auto-aof-rewrite-min-sizeelle est définie sur 64 Mo et auto-aof-rewrite-percentagesur 100 %, la réécriture automatique ne sera déclenchée que si la taille du fichier AOF dépasse 64 Mo et a augmenté de 100 % ou plus depuis la dernière réécriture.

Déclencher automatiquement la réécriture des fichiers AOF permet de garantir que les fichiers AOF ne grossissent pas sans limite et d'éviter d'effectuer des opérations de réécriture trop fréquemment. Cela peut maintenir le fichier AOF à une taille raisonnable sans perdre de données, améliorer les performances et réduire l'utilisation de l'espace disque.

Flux d'exécution réécrit d'AOP

Le flux d'exécution de la réécriture AOP est le suivant :

Effectuer une demande de réécriture AOF.
- Si le processus en cours effectue une réécriture AOF, la requête n'est pas exécutée.
- Si le processus en cours effectue une opération bgsave, la commande de réécriture sera retardée jusqu'à la fin de bgsave.
Le processus parent exécute fork pour créer un processus enfant.
Processus de réécriture :
a. Le processus principal continue de répondre aux autres commandes après le fork. Toutes les opérations de modification seront écrites dans le tampon AOF et synchronisées sur le disque dur conformément à la politique appendfsync pour garantir l'exactitude de l'ancien mécanisme de fichier AOF.
b. Le processus enfant ne dispose que de toutes les informations de mémoire avant le fork, le processus parent doit donc écrire les opérations de modification pendant la période suivant le fork dans le tampon de réécriture AOF.
Le processus enfant fusionne les commandes dans un nouveau fichier AOF basé sur l'instantané de mémoire.
Le processus enfant termine la réécriture :
a. Une fois le nouveau fichier écrit, le processus enfant envoie un signal au processus parent.
b. Le processus parent ajoute les commandes temporairement enregistrées dans le tampon de réécriture AOF au nouveau fichier AOF.
c. Remplacez l'ancien fichier AOF par le nouveau fichier AOF.

4. Persistance mitigée

La persistance hybride signifie que Redis utilise à la fois les méthodes de persistance AOF (Append-Only File) et RDB (Redis Database) pour garantir la durabilité des données. Cette stratégie combine deux méthodes de persistance différentes pour tenir compte de différents besoins et scénarios.

Voici comment fonctionne la persistance hybride et ses avantages :

1. Persistance AOF :

AOF est un fichier journal d'écriture ajouté qui enregistre les commandes pour chaque opération d'écriture et les paramètres de ces commandes.
La persistance AOF est en temps réel, c'est-à-dire que chaque opération d'écriture est ajoutée au fichier AOF, garantissant ainsi l'intégrité des données.
Les fichiers AOF peuvent être utilisés pour la récupération de données et Redis peut reconstruire l'état des données en réexécutant les commandes dans les fichiers AOF.

2. Persistance RDB :

RDB est une persistance d'instantané qui enregistre les données de la mémoire Redis sur le disque sous forme binaire.
La persistance RDB est point à point, c'est-à-dire qu'un fichier instantané est généré dans un intervalle de temps spécifié, généralement après la modification des données de la mémoire.
Un fichier RDB est un fichier binaire compressé utilisé pour restaurer rapidement l'état de l'ensemble de la base de données en cas de besoin.

Comment fonctionne la persistance hybride :

Redis active les méthodes de persistance AOF et RDB.
Les fichiers AOF enregistrent chaque opération d'écriture, tandis que les fichiers RDB génèrent des instantanés à des intervalles spécifiques.
Lors de la récupération des données, Redis essaiera d'abord d'utiliser le fichier AOF pour la récupération, car il contient plus de commandes historiques et peut fournir une récupération de données plus complète.
Si le fichier AOF est endommagé ou trop volumineux, Redis peut utiliser le fichier RDB pour un démarrage rapide, puis effectuer une réparation des données basée sur le fichier AOF.

Avantages de la persistance hybride :

Sécurité des données : AOF fournit des ajouts de données en temps réel et des enregistrements historiques, ce qui rend les données plus sécurisées. RDB fournit une méthode de récupération rapide.
Performances : les opérations d'écriture AOF sont plus efficaces que RDB et RDB permet une récupération rapide des données.
Flexibilité : la persistance hybride vous permet de choisir la méthode de récupération appropriée en fonction de différents besoins et scénarios.
Réduisez la perte de données : étant donné que les fichiers AOF contiennent des opérations historiques, le risque de perte de données peut être réduit.

En bref, la persistance hybride combine les deux méthodes de persistance AOF et RDB, prend en compte les performances et la récupération en temps réel, fournit une stratégie de protection des données plus complète et rend Redis plus puissant et plus fiable dans différents scénarios d'application. Cependant, il convient de noter que la persistance hybride peut augmenter la surcharge de stockage et la charge d'E/S disque. Une attention particulière est donc nécessaire lors de la configuration.