Exemple d'analyse de la persistance AOF dans Redis

1. Introduction à AOF

RDB est une méthode de persistance qui peut enregistrer l'état de la base de données en stockant des paires clé-valeur dans la base de données. AOF est une méthode de persistance qui enregistre l'état de la base de données en enregistrant les commandes d'écriture exécutées par le serveur Redis.

　Par exemple, pour la commande suivante :

　

　 La méthode de persistance RDB consiste à enregistrer les trois paires clé-valeur de str1, str2 et str3 dans le fichier RDB, tandis que la persistance AOF consiste à exécuter l'ensemble, sadd et lpush trois commandes sont enregistrées dans le fichier AOF.

2. Configuration AOF

　Sous APPEND ONLY MODE dans le fichier de configuration redis.conf :

　

　①, appendonly : La valeur par défaut est non, ce qui signifie que redis utilise la persistance rdb par défaut. Persistance AOF, vous devez changer en annexe seulement par oui.

　　②、appendfilename：aof nom de fichier, la valeur par défaut est "appendonly.aof"

　③、appendfsync：aof configuration de la stratégie de persistance

　　 cela ne signifie pas ne pas exécuter fsync, et le système d'exploitation garantira que le les données sont synchronisées sur le disque, le plus rapide, mais pas très sûr ;

　 Signifie toujours que fsync est exécuté à chaque écriture pour garantir que les données sont synchronisées sur le disque, ce qui est très inefficace

L'option "everysec" qui exécute fsync une fois par seconde peut entraîner la perte des données en 1 seconde. Choisissez généralement chaque seconde pour équilibrer sécurité et efficacité.

　 ④, no-appendfsync-on-rewrite : lorsque aof est réécrit ou écrit dans un fichier rdb, une grande quantité d'E/S sera effectuée à ce moment-là, pour chaque mode et toujours aof, l'exécution de fsync entraînera le blocage d'un. longtemps. Le champ no-appendfsync-on-rewrite est défini sur no par défaut. Si l'application a des exigences de latence élevées, ce champ peut être défini sur oui, sinon il est défini sur non, ce qui constitue un choix plus sûr pour la fonctionnalité de persistance. Le définir sur yes signifie que les nouvelles opérations d'écriture ne seront pas fsyncd pendant la réécriture, et seront temporairement stockées dans la mémoire et seront écrites une fois la réécriture terminée. La valeur par défaut est non, et oui est recommandé. La politique fsync par défaut de Linux est de 30 secondes. 30 secondes de données peuvent être perdues. La valeur par défaut est non.

La valeur par défaut du pourcentage de réécriture automatique est de 100. aof configuration de réécriture automatique, lorsque la taille actuelle du fichier aof dépasse le pourcentage de la dernière taille du fichier aof réécrit, il sera réécrit, c'est-à-dire que lorsque le fichier aof atteint une certaine taille, Redis peut appeler bgrewriteaof pour réécrire le fichier journal. Lorsque la taille du fichier AOF atteint le double de la taille de la dernière réécriture du journal (définie sur 100), un nouveau processus de réécriture du journal sera automatiquement démarré.

auto-aof-rewrite-min-size est défini sur 64 Mo. Pour éviter d'avoir à réécrire lorsque le pourcentage convenu est atteint, vous pouvez définir une taille minimale de fichier.

　⑦, aof-load-truncated : Le fichier aof peut être incomplet à la fin Lorsque redis démarre, les données du fichier aof sont chargées dans la mémoire. Le redémarrage peut se produire après la panne du système d'exploitation hôte où se trouve Redis, en particulier si le système de fichiers ext4 n'ajoute pas l'option data=ordered. Ce phénomène se produit. Un temps d'arrêt de Redis ou une interruption anormale ne rendront pas la queue incomplète. Vous pouvez choisir de laisser Redis se fermer ou d'importer autant de données que possible. Une fois l'option oui sélectionnée, un journal sera automatiquement envoyé au client et chargé lors de l'importation du fichier aof tronqué. Si la réponse est non, l'utilisateur doit exécuter manuellement la commande redis-check-aof pour réparer le fichier AOF. La valeur par défaut est oui.

3. Activez AOF

Modifiez la configuration en annexe de redis.conf sur oui.

　　L'emplacement où AOF enregistre les fichiers est le même que l'emplacement où RDB enregistre les fichiers. Ils sont configurés via le répertoire du fichier de configuration redis.conf :

　　

　Vous pouvez obtenir le chemin enregistré via la commande config get dir. .

4. Récupération du fichier AOF

　Après le redémarrage de Redis, le fichier AOF sera chargé.

　Commande de réparation d'exception : redis-check-aof --fix to repair

5. Réécriture d'AOF

Étant donné que la persistance d'AOF est que Redis enregistre en permanence les commandes d'écriture dans le fichier AOF, à mesure que Redis continue de progresser, AOF Le fichier deviendra de plus en plus gros. Plus le fichier est volumineux, plus la mémoire du serveur sera occupée et plus la récupération AOF sera longue. Afin de résoudre ce problème, Redis a ajouté un nouveau mécanisme de réécriture lorsque la taille du fichier AOF dépasse le seuil défini, Redis démarre la compression du contenu du fichier AOF, en ne conservant que le jeu d'instructions minimum permettant de récupérer les données. Vous pouvez utiliser la commande bgrewriteaof pour le réécrire.

　Par exemple, pour les commandes suivantes :

　

Si le fichier AOF n'est pas réécrit, le fichier AOF enregistrera quatre commandes SADD. Si la réécriture AOF est utilisée, seule la commande suivante sera retenue dans le fichier AOF :

1	sadd animals "dog" "tiger" "panda" "lion" "cat"

　C'est-à-dire que la réécriture de fichier AOF ne réorganise pas le fichier d'origine, mais lit directement les paires clé-valeur existantes du serveur, puis utilise une commande pour remplacer les multiples commandes qui ont précédemment enregistré cette paire clé-valeur, générez un nouveau fichier et remplacez le fichier AOF d'origine.

　　Mécanisme de déclenchement de la réécriture du fichier AOF : via auto-aof-rewrite-percentage dans le fichier de configuration redis.conf : la valeur par défaut est 100, et auto-aof-rewrite-min-size : configuration de 64 Mo, ce qui signifie le Redis par défaut La taille AOF au moment de la dernière réécriture sera enregistrée. La configuration par défaut est de se déclencher lorsque la taille du fichier AOF est le double de la taille après la dernière réécriture et que le fichier est supérieur à 64 Mo.

　

Permettez-moi de le mentionner à nouveau, nous savons que Redis est un travail monothread si la réécriture d'AOF prend beaucoup de temps, alors lors de la réécriture d'AOF, Redis ne pourra pas traiter d'autres commandes pendant longtemps. , ce qui est évidemment intolérable. Afin de surmonter ce problème, la solution de Redis est de mettre le programme de réécriture AOF dans un sous-programme. Cela présente deux avantages : 　　① Lors de la réécriture AOF du processus enfant, le processus serveur (processus parent) peut continuer à traiter d'autres commandes. .

L'utilisation de processus enfants au lieu de threads peut éviter d'utiliser des verrous et garantir la sécurité des données, car le processus enfant possède une copie des données du processus parent.

　L'utilisation de sous-processus résout le problème ci-dessus, mais de nouveaux problèmes surviennent également : comme le processus serveur traite toujours d'autres commandes lors de la réécriture AOF du sous-processus, cette nouvelle commande peut également modifier la base de données. Cela crée la base de données actuelle. L'état et l'état du fichier AOF réécrit sont incohérents.

　Afin de résoudre le problème d'état des données incohérent, le serveur Redis configure un tampon de réécriture AOF. Ce tampon est utilisé après la création du processus enfant. Lorsque le serveur Redis exécute une commande d'écriture, la commande d'écriture sera envoyée à. Tampon de réécriture AOF. Lorsque le processus enfant termine la réécriture AOF, il enverra un signal au processus parent. Une fois que le processus parent aura reçu le signal, il appellera une fonction pour écrire le contenu du tampon de réécriture AOF dans le nouveau fichier AOF.

　Cela minimise l'impact de la réécriture AOF sur le serveur.

6. Avantages et inconvénients d'AOF

Avantages :

　① La méthode de persistance AOF fournit une variété de fréquences de synchronisation Même si la fréquence de synchronisation par défaut est utilisée pour synchroniser une fois par seconde, Redis ne perdra qu'une seconde de données. la plupart. .

　②. Les fichiers AOF sont construits à l'aide de l'ajout de commande Redis. Par conséquent, même si Redis ne peut écrire que des fragments de commande dans le fichier AOF, il est facile de corriger le fichier AOF à l'aide de l'outil redis-check-aof.

Le format des fichiers AOF est facile à lire, ce qui permet aux utilisateurs de les traiter avec plus de flexibilité. Par exemple, si nous utilisons accidentellement la commande FLUSHALL par erreur, avant que la réécriture ne soit en cours, nous pouvons supprimer manuellement la dernière commande FLUSHALL puis utiliser AOF pour récupérer les données.

　Inconvénients :

　① Pour Redis avec les mêmes données, les fichiers AOF sont généralement plus gros que les fichiers RDF.

La fréquence de synchronisation par défaut d'AOF, une fois par seconde, offre une variété d'options de fréquence de synchronisation, mais ses performances restent élevées. Lorsque la charge Redis est élevée, RDB offre de meilleures garanties de performances qu'AOF.

　③. RDB utilise des instantanés pour conserver l'intégralité des données Redis, tandis qu'AOF ajoute uniquement chaque commande exécutée au fichier AOF. Par conséquent, en théorie, RDB est plus robuste qu'AOF. Selon la documentation officielle, AOF présente des bugs que RDB n'a pas.

　Alors comment choisir entre les deux méthodes de persistance, AOF et RDB ?

　Si vous pouvez tolérer la perte de données sur une courte période de temps, il ne fait aucun doute que l'utilisation de RDB est la meilleure. Générer régulièrement des instantanés RDB est très pratique pour la sauvegarde de la base de données, et la vitesse de récupération RDB des ensembles de données l'est également. plus rapide que la récupération AOF. Elle devrait être rapide, et l'utilisation de RDB peut également éviter certains bugs cachés d'AOF, sinon, utilisez la réécriture AOF ; Cependant, il est généralement recommandé de ne pas utiliser un certain mécanisme de persistance seul, mais d'utiliser les deux ensemble. Dans ce cas, lorsque Redis redémarre, le fichier AOF sera chargé en premier pour restaurer les données d'origine, car dans des circonstances normales, l'ensemble de données est enregistré. dans le fichier AOF est plus complet que l'ensemble de données enregistré dans le fichier RDB. Peut-être qu'à l'avenir, les responsables de Redis fusionneront les deux méthodes de persistance en un seul mode de persistance.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!