MISCONF Redis est configuré pour enregistrer des instantanés RDB

Si vous rencontrez l’erreur et que certaines données importantes ne peuvent pas être supprimées sur l’instance redis en cours d’exécution (problèmes liés aux permissions pour le fichier rdb ou son répertoire incorrect ou espace disque rdb ), vous pouvez toujours redirect le fichier rdb autre.

En utilisant redis-cli , vous pouvez faire quelque chose comme ceci:

 CONFIG SET dir /tmp/some/directory/other/than/var CONFIG SET dbfilename temp.rdb 

Après cela, vous souhaiterez peut-être exécuter une commande BGSAVE pour vous assurer que les données seront écrites dans le fichier rdb . Assurez-vous que lorsque vous exécutez INFO , bgsave_in_progress est déjà à 0 (l’opération est réussie ou une erreur est bgsave_in_progress ). Après cela, vous pouvez maintenant commencer à sauvegarder le fichier rdb généré en rdb sécurité.

Vous pouvez l’arrêter en essayant de sauvegarder l’instantané:

 config set stop-writes-on-bgsave-error no 

Ceci est une solution rapide, mais si vous vous souciez des données que vous utilisez, vous devriez vérifier pour savoir pourquoi bgsave a échoué à la première place.

Il pourrait y avoir des erreurs pendant le processus de Bgsave à cause de la mémoire insuffisante. Essayez ceci (à partir de la sauvegarde de l’arrière-plan de redis)

 echo 'vm.overcommit_memory = 1' >> /etc/sysctl.conf sysctl vm.overcommit_memory=1 

Juste trop bref sur la réponse. ouvrir le terminal et taper les commandes suivantes

 redis-cli 

et maintenant tapez

 config set stop-writes-on-bgsave-error no 

Merci à tous pour avoir vérifié le problème, apparemment l’erreur a été bgsave lors de bgsave .

Pour moi, taper config set stop-writes-on-bgsave-error no dans un shell et redémarrer Redis a résolu le problème.

Si vous travaillez sur une machine Linux, vérifiez également les permissions de fichier et de dossier de la firebase database.

La firebase database et son chemin peuvent être obtenus via:

en redis-cli :

CONFIG GET dir

CONFIG GET dbfilename

et dans la ligne de commande ls -l . Les permissions pour le répertoire doivent être 755 et celles du fichier doivent être 644 . En outre, normalement redis-server s’exécute au fur et à mesure que l’utilisateur redis , donc il est également intéressant de donner à l’utilisateur la propriété du dossier en exécutant sudo chown -R redis:redis /path/to/rdb/folder . Cela a été développé dans la réponse ici .

Démarrez Redis Server dans un répertoire où Redis dispose d’permissions en écriture

Les réponses ci-dessus vont certainement résoudre votre problème, mais voici ce qui se passe réellement:

L’emplacement par défaut pour stocker le fichier rdb.dump est ./ (indiquant le répertoire actuel). Vous pouvez le vérifier dans votre fichier redis.conf . Par conséquent, le répertoire à partir duquel vous démarrez le serveur redis est l’endroit où un fichier dump.rdb sera créé et mis à jour.

Il semble que vous ayez commencé à exécuter le serveur redis dans un répertoire où redis ne dispose pas des permissions dump.rdb pour créer le fichier dump.rdb .

Pour ne rien arranger, redis ne vous permettra probablement pas non plus d’arrêter le serveur tant qu’il ne sera pas capable de créer le fichier rdb pour garantir une sauvegarde correcte des données.

Pour résoudre ce problème, vous devez accéder à l’environnement client redis actif à l’aide de redis-cli , mettre à jour la clé dir et définir sa valeur dans votre dossier de projet ou dans tout dossier dans lequel non-root est autorisé à enregistrer. Exécutez ensuite BGSAVE pour appeler la création du fichier dump.rdb .

 CONFIG SET dir "/hardcoded/path/to/your/project/folder" BGSAVE 

(Maintenant, si vous devez enregistrer le fichier dump.rdb dans le répertoire dans lequel vous avez démarré le serveur, vous devrez modifier les permissions du répertoire pour que redis puisse y écrire. Vous pouvez rechercher stackoverflow pour savoir comment procéder. ).

Vous devriez maintenant pouvoir arrêter le serveur redis. Notez que nous avons codé le chemin d’access. Le codage en dur est rarement une bonne pratique et je recommande fortement de démarrer le serveur redis à partir du répertoire de votre projet et de changer la dir key back to . / `.

 CONFIG SET dir "./" BGSAVE 

De cette façon, lorsque vous avez besoin de redis pour un autre projet, le fichier de vidage sera créé dans le répertoire de votre projet actuel et non dans le répertoire du projet du chemin d’access codé.

Une solution plus permanente consisterait à chercher dans /etc/redis/redis.conf autour des lignes 200-250. Il existe des parameters pour les fonctionnalités rdb, qui ne faisaient pas partie des redis dans les jours 2.x.

notamment

 dir ./ 

peut être changé pour

 dir /home/someuser/redislogfiledirectory 

ou vous pouvez commenter toutes les lignes de sauvegarde, et ne pas vous soucier de la persistance. (Voir les commentaires dans /etc/redis/redis.conf)

Aussi, n’oubliez pas

 service redis-server stop service redis-server start 

FWIW, je me suis heurté à cela et la solution consistait simplement à append un fichier d’échange à la boîte. J’ai utilisé cette méthode: https://www.digitalocean.com/community/tutorials/how-to-add-swap-on-ubuntu-14-04

toutes ces réponses n’expliquent pas la raison pour laquelle la sauvegarde rdb a échoué.

comme mon cas, j’ai vérifié le journal redis et trouvé:

14975: M 18 juin 13: 23: 07.354 # Sauvegarde de l’arrière-plan terminée par le signal 9

exécuter la commande suivante dans le terminal:

 sudo egrep -i -r 'killed process' /var/log/ 

il affiche:

/var/log/kern.log.1:Jun 18 13:23:07 10-10-88-16 kernel: [28152358.208108] Processus tué 28416 (redis-server) total-vm: 7660204kB, anon-rss: 2285492kB, fichier-rss: 0kB

c’est ça! ce processus (redis save rdb) est tué par OOM killer

fait référence:

https://github.com/antirez/redis/issues/1886

Trouver quel processus a été tué par Linux OOM killer

Cette erreur se produit à cause de l’échec de BGSAVE. Au cours de BGSAVE, Redis crée un processus enfant pour enregistrer les données sur le disque. Bien que la raison exacte de l’échec de BGSAVE puisse être vérifiée à partir des journaux (généralement dans /var/log/redis/redis-server.log sur les machines Linux), BGAVE échoue souvent parce que fork ne peut pas allouer de mémoire. Plusieurs fois, fork ne parvient pas à allouer de la mémoire (bien que la machine ait suffisamment de RAM disponible) en raison d’une optimisation contradictoire par le système d’exploitation.

Comme on peut le lire dans la FAQ de Redis :

Le schéma de sauvegarde en arrière-plan de Redis repose sur la sémantique de fork dans les systèmes d’exploitation modernes: redis forks (crée un processus enfant) qui est une copie exacte du parent. Le processus enfant vide la firebase database sur le disque et quitte finalement. En théorie, l’enfant devrait utiliser autant de mémoire que le parent étant une copie, mais en réalité, grâce à la sémantique de la copie sur écriture mise en œuvre par la plupart des systèmes d’exploitation modernes, le processus parent et enfant partagera les pages de mémoire communes. Une page sera dupliquée uniquement lorsqu’elle change dans l’enfant ou dans le parent. Puisque, en théorie, toutes les pages peuvent changer pendant que le processus fils enregistre, Linux ne peut pas savoir à l’avance la quantité de mémoire que l’enfant va prendre. Par conséquent, si le paramètre oversommit_memory est défini sur zéro, il échouera Il est nécessaire de dupliquer toutes les pages de la mémoire parente, de sorte que si vous disposez d’un dataset Redis de 3 Go et de seulement 2 Go de mémoire libre, cela échouera.

Régler oversommit_memory à 1 indique que Linux se détend et exécute le fork de manière plus optimiste, et c’est bien ce que vous voulez pour Redis.

Redis ne nécessite pas autant de mémoire que le système d’exploitation pense qu’il peut écrire sur le disque.

Pour résoudre ce problème, vous pouvez:

Modifiez /etc/sysctl.conf et ajoutez:

 vm.overcommit_memory=1 

Puis redémarrez sysctl avec:

Sur FreeBSD:

 sudo /etc/rc.d/sysctl reload 

Sous Linux:

 sudo sysctl -p /etc/sysctl.conf 

Comme le souligne @Chris, le problème risque de ne plus avoir de mémoire. Nous avons commencé à en faire l’expérience lorsque nous avons alloué trop de RAM à MySQL ( innodb_buffer_pool_size ).

Pour garantir une quantité de RAM suffisante pour Redis et les autres services, nous avons réduit innodb_buffer_pool_size sur MySQL.

J’ai rencontré ce problème en travaillant sur un serveur avec de l’espace disque AFS car mon jeton d’authentification avait expiré, ce qui a généré des réponses avec Permission Denied lorsque le serveur redis tentait de sauvegarder. J’ai résolu ce problème en rafraîchissant mon jeton:

kinit USERNAME_HERE -l 30d && aklog

Dans mon cas, la raison était un espace libre très faible sur le disque (seulement 35 Mo). J’ai fait ce qui suit –

1. Arrêt de tous les processus liés à Redis
2. Supprimer des fichiers sur le disque pour libérer de l’espace

3. Supprimer le fichier de vidage de redis (si les données existantes ne sont pas nécessaires)

   sudo rm /var/lib/redis/*

4. Supprimer toutes les clés de toutes les bases de données existantes

   sudo redis-cli flushall

5. redémarrez toutes les tâches de céleri et vérifiez les journaux correspondants pour tout problème

Moi aussi, j’étais confronté au même problème. Les deux réponses (la plus votée et la plus acceptée) donnent simplement une solution temporaire pour la même chose.

De plus, le config set stop-writes-on-bgsave-error no est une façon horrible de config set stop-writes-on-bgsave-error no cette erreur, puisque cette option empêche que redis ne signale que les écritures ont été arrêtées et de continuer sans écrire les données dans une instantané. Ceci ignore simplement cette erreur. Référer ceci

En ce qui concerne la configuration de dir in config dans redis-cli, une fois que vous redémarrez le service redis, celui-ci doit être effacé et la même erreur doit réapparaître. La valeur par défaut de dir dans redis.conf est ./ , et si vous démarrez redis en tant qu’utilisateur root, alors ./ est / à laquelle les permissions d’écriture ne sont pas accordées, et donc l’erreur.

Le meilleur moyen est de définir le paramètre dir dans le fichier redis.conf et de définir les permissions appropriées sur ce répertoire. La plupart des dissortingbutions debian doivent l’avoir dans /etc/redis/redis.conf

Si vous utilisez Redis localement sur une machine Windows, essayez de “courir en tant qu’administrateur” et voyez si cela fonctionne. Avec moi, le problème était que Redis se trouvait dans le dossier “Program Files”, ce qui limite les permissions par défaut. Comme il se doit.

Cependant, ne lancez pas automatiquement Redis en tant qu’administrateur. Vous ne voulez pas lui accorder plus de droits qu’il est censé avoir. Vous voulez résoudre cela par le livre.

Nous avons donc pu identifier rapidement le problème en l’exécutant en tant qu’administrateur, mais ce n’est pas la solution. Un scénario probable est que vous avez placé Redis dans un dossier qui n’a pas de droits d’écriture et, par conséquent, le fichier de firebase database est stocké dans ce même emplacement.

Vous pouvez résoudre ce problème en ouvrant le redis.windows.conf et en recherchant la configuration suivante:

# The working directory. # # The DB will be written inside this directory, with the filename specified # above using the 'dbfilename' configuration directive. # # The Append Only File will also be created inside this directory. # # Note that you must specify a directory here, not a file name. dir ./

Changez le dir ./

Vous pouvez également déplacer le dossier Redis dans son intégralité dans un dossier qui, à votre connaissance, dispose des permissions appropriées.

Avait rencontré cette erreur et était capable de comprendre à partir du journal que l’erreur est due au fait que l’espace disque n’est pas suffisant. Toutes les données insérées dans mon cas n’étaient plus nécessaires. J’ai donc essayé de FLUSHALL. Comme le processus redis-rdb-bgsave était en cours, il ne permettait pas de FLUSH les données également. J’ai suivi les étapes ci-dessous et j’ai pu continuer.

1. Connectez-vous au client redis
2. Exécuter la configuration définie stop-write-on-bgsave-error no
3. Exécuter FLUSHALL (les données stockées n’étaient pas nécessaires)
4. Execute set config set stop-écrit-sur-bgsave-error oui

Le processus redis-rdb-bgsave ne fonctionnait plus après les étapes ci-dessus.

Solution à @Govind Rai ‘pour enregistrer le fichier dump.rdb dans le répertoire dans lequel vous avez démarré le serveur’:

Cliquez avec le bouton droit sur votre dossier Redis, cliquez sur Propriétés, puis sur l’onglet Sécurité. Cliquez sur Modifier pour ouvrir la boîte de dialog Autorisations pour.

Cliquez sur tous les forfaits d’application

Dans la zone Autorisations pour, sélectionnez la case à cocher Autoriser ‘Contrôle total’.