Pendant l'écriture dans Redis ( SET foo bar
), j'obtiens l'erreur suivante:
MISCONF Redis est configuré pour enregistrer les instantanés RDB, mais n'est actuellement pas en mesure de persister sur le disque. Les commandes susceptibles de modifier l'ensemble de données sont désactivées. Veuillez consulter les journaux Redis pour plus de détails sur l'erreur.
Fondamentalement, je comprends que le problème est que redis n'est pas en mesure d'enregistrer des données sur le disque, mais je n'ai aucune idée de la façon de se débarrasser du problème.
De plus, la question suivante a le même problème, elle a été abandonnée il y a longtemps sans réponse et probablement sans tentative de résoudre le problème.
redis
, mais cela n'aide pas!Réponses:
Si vous rencontrez l'erreur et que certaines données importantes ne peuvent pas être supprimées sur l'instance de redis en cours d'exécution (problèmes avec les autorisations pour le
rdb
fichier ou son répertoire de manière incorrecte ou manque d'espace disque), vous pouvez toujours rediriger lerdb
fichier pour qu'il soit écrit ailleurs.En utilisant
redis-cli
, vous pouvez faire quelque chose comme ceci:Après cela, vous souhaiterez peut-être exécuter une
BGSAVE
commande pour vous assurer que les données seront écrites dans lerdb
fichier. Assurez-vous que lorsque vous exécutezINFO persistence
,bgsave_in_progress
est déjà0
etrdb_last_bgsave_status
estok
. Après cela, vous pouvez maintenant commencer à sauvegarder lerdb
fichier généré dans un endroit sûr.la source
dir C:/Temp/
. Faites un bgsave pour vérifier que cela fonctionne ..À l'aide de
redis-cli
, vous pouvez l'arrêter en essayant d'enregistrer l'instantané:Il s'agit d'une solution de contournement rapide, mais si vous vous souciez des données pour lesquelles vous les utilisez, vous devez vérifier pour s'assurer pourquoi bgsave a échoué en premier lieu.
la source
Il peut y avoir des erreurs pendant le processus bgsave en raison d'une mémoire insuffisante. Essayez ceci (à partir de l'arrière-plan de sauvegarde de FAQ)
la source
Cette erreur se produit en raison de l'échec de BGSAVE. Pendant BGSAVE, Redis lance 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
/var/log/redis/redis-server.log
sur les machines Linux), mais la plupart du temps BGAVE échoue parce que le fork ne peut pas allouer de mémoire. Plusieurs fois, le fork ne parvient pas à allouer de la mémoire (bien que la machine dispose de suffisamment de RAM disponible) en raison d'une optimisation conflictuelle par le système d'exploitation.Comme on peut le lire dans la FAQ Redis :
Redis n'a pas besoin d'autant de mémoire que le système d'exploitation le pense pour écrire sur le disque, il peut donc échouer de manière préventive.
Pour résoudre ce problème, vous pouvez:
Modifiez
/etc/sysctl.conf
et ajoutez:Redémarrez ensuite sysctl avec:
Sur FreeBSD:
Sous Linux:
la source
systemctl status redis
révèle qu'il y a un avertissement qui suggère de changer exactement leovercommit_memory=0
paramètre. Modifier cela a en effet résolu le problème pour moi.Redémarrez votre serveur redis.
brew services restart redis
.sudo service redis restart
/sudo systemctl restart redis
services.msc
, Enter-> RechercherRedis
puis cliquez surrestart
.J'ai personnellement eu ce problème après la mise à niveau de redis avec Brew (
brew upgrade
). Après avoir redémarré l'ordinateur portable, cela a immédiatement fonctionné.la source
sudo
:brew services stop redis; sudo brew services start redis
.dans le cas où vous travaillez sur une machine Linux, revérifiez également les autorisations de fichier et de dossier de la base de données.
Le db et son chemin peuvent être obtenus via:
dans
redis-cli
:et dans la ligne de commande
ls -l
. Les autorisations pour le répertoire doivent être 755 et celles pour le fichier doivent être 644 . En outre, normalement redis-server s'exécute en tant qu'utilisateurredis
, il est donc également agréable de donner à l'utilisateurredis
la propriété du dossier en l'exécutantsudo chown -R redis:redis /path/to/rdb/folder
. Ceci a été développé dans la réponse ici .la source
Merci à tous d'avoir vérifié le problème, apparemment l'erreur a été produite pendant
bgsave
.Pour moi, taper
config set stop-writes-on-bgsave-error no
un shell et redémarrer Redis a résolu le problème.la source
Démarrez Redis Server dans un répertoire où Redis a des autorisations d'é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
rdb.dump
fichier est./
(indiquant le répertoire actuel). Vous pouvez le vérifier dans votreredis.conf
dossier. Par conséquent, le répertoire à partir duquel vous démarrez le serveur redis est l'endroit où undump.rdb
fichier 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 autorisations appropriées pour créer le
dump.rdb
fichier.Pour aggraver les choses, redis ne vous permettra probablement pas non plus d'arrêter le serveur tant qu'il ne sera pas en mesure de créer le fichier rdb pour garantir la bonne sauvegarde des données.
Pour résoudre ce problème, vous devez vous rendre dans l'environnement client redis actif à l'aide de
redis-cli
ladir
clé et la mettre à jour, puis définir sa valeur dans votre dossier de projet ou dans tout dossier dans lequel un utilisateur non root dispose d'autorisations d'enregistrement. Exécutez ensuiteBGSAVE
pour appeler la création dudump.rdb
fichier.(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 autorisations pour le répertoire afin 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é en dur le chemin. Le codage en dur est rarement une bonne pratique et je recommande fortement de démarrer le serveur redis à partir de votre répertoire de projet et de changer le
dir key back to
. / `.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 de projet du chemin codé en dur.
la source
redis
sudo chown redis:redis /var/lib/redis
Si vous utilisez MacOS et avez récemment mis à niveau vers Catalina, vous devrez peut-être exécuter
brew services restart redis
comme suggéré dans ce problème .la source
A rencontré cette erreur et a pu comprendre à partir du journal que l'erreur était due au fait que l'espace disque n'était pas suffisant. Toutes les données qui ont été 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 d'exécution, il ne permettait pas non plus de RINÇER les données. J'ai suivi les étapes ci-dessous et j'ai pu continuer.
Le processus redis-rdb-bgsave ne s'exécutait plus après les étapes ci-dessus.
la source
J'ai rencontré le même problème, la principale raison derrière cela était la consommation de mémoire (RAM) par redis. Ma machine EC2 avait 8 Go de RAM (environ 7,4 disponibles pour la consommation)
Lorsque mon programme était en cours d'exécution, l'utilisation de la RAM est passée à 7,2 Go, ce qui laisse à peine ~ 100 Mo de RAM, ce qui déclenche généralement la
MISCONF Redis error ...
Vous pouvez déterminer la consommation de RAM à l'aide de la
htop
commande. Recherchez l' attribut Mem après avoir exécuté la commande htop. S'il montre une consommation élevée (comme dans mon cas, c'était 7,2 Go / 7,4 Go), il est préférable de mettre à niveau l'instance avec une mémoire plus grande. Dans ce scénario, l'utilisationconfig set stop-writes-on-bgsave-error no
sera une catastrophe pour le serveur et peut entraîner la perturbation d'autres services en cours d'exécution sur le serveur (le cas échéant). Donc, il vaut mieux éviter la commande config et METTRE À NIVEAU VOTRE MACHINE REDIS .Pour info: vous devrez peut-être installer htop pour que cela fonctionne:
sudo apt-get install htop
Une autre solution à cela peut être un autre service lourd RAM exécuté sur votre système, recherchez un autre service en cours d'exécution sur votre serveur / machine / instance et arrêtez-le si ce n'est pas nécessaire. Pour vérifier tous les services exécutés sur votre machine, utilisez
service --status-all
Et une suggestion pour les personnes qui collent directement la commande config, veuillez effectuer une nouvelle recherche et avertir au moins l'utilisateur avant d'utiliser de telles commandes. Et comme @Rodrigo l'a mentionné dans son commentaire: "Cela n'a pas l'air cool d'ignorer les erreurs."
---MISE À JOUR---
Vous pouvez également configurer
maxmemory
etmaxmemory-policy
définir le comportement de Redis lorsqu'une limite de mémoire spécifique est atteinte. Par exemple, si je souhaite conserver la limite de mémoire de 6 Go et supprimer les clés les moins récemment utilisées de la base de données pour m'assurer que l'utilisation de redis mem ne dépasse pas 6 Go, nous pouvons définir ces deux paramètres (dans redis.conf ou CONFIG SET commander):Il y a beaucoup d'autres valeurs que vous pouvez définir pour ces deux paramètres que vous pouvez lire à ce sujet ici: https://redis.io/topics/lru-cache
la source
Un correctif plus permanent pourrait être de regarder dans /etc/redis/redis.conf autour des lignes 200-250, il y a des paramètres pour les fonctionnalités rdb, qui ne faisaient pas partie de redis dans les jours 2.x.
notamment
peut être changé en
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)
N'oubliez pas non plus
la source
toutes ces réponses n'expliquent pas la raison de l'échec de la sauvegarde rdb.
comme mon cas, j'ai vérifié le journal redis et trouvé:
exécutez la commande suivante dans le terminal:
il affiche:
c'est ça! ce processus (redis save rdb) est tué par le tueur OOM
se réfère:
https://github.com/antirez/redis/issues/1886
Trouver quel processus a été tué par le tueur Linux OOM
la source
FWIW, je suis tombé sur cela et la solution était d'ajouter simplement 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
la source
Moi aussi, je faisais face au même problème. Les deux réponses (la plus votée et la plus acceptée) donnent juste une correction temporaire pour la même chose.
De plus,
config set stop-writes-on-bgsave-error no
c'est une façon horrible de passer outre cette erreur, car ce que cette option fait est d'empêcher redis de signaler que les écritures ont été arrêtées et de continuer sans écrire les données dans un instantané. C'est simplement ignorer cette erreur. Référez ceciQuant à la configuration
dir
dansconfig
redis-cli, une fois que vous redémarrez le service redis, cela sera également effacé et la même erreur réapparaîtra. La valeur par défaut dedir
inredis.conf
est./
, et si vous démarrez redis en tant qu'utilisateur root,./
est alors/
auquel les autorisations d'écriture ne sont pas accordées, et donc l'erreur.La meilleure façon est de définir le
dir
paramètre dans le fichier redis.conf et de définir les autorisations appropriées sur ce répertoire. La plupart des distributions Debian l’ont dans/etc/redis/redis.conf
la source
De nos jours, les problèmes d'accès en écriture Redis qui transmettent ce message d'erreur au client sont réapparus dans les
redis
conteneurs Docker officiels .Redis à partir de l'
redis
image officielle essaie d'écrire le fichier .rdb dans le/data
dossier conteneurs , ce qui est plutôt regrettable, car il s'agit d'un dossier appartenant à la racine et il s'agit également d'un emplacement non persistant (les données écrites y disparaîtront si votre conteneur / pod plante).Donc, après une heure d'inactivité, si vous avez exécuté votre
redis
conteneur en tant qu'utilisateur non root (par exempledocker run -u 1007
plutôt que par défautdocker run -u 0
), vous obtiendrez un message d'erreur bien détaillé dans votre journal de serveur (voirdocker logs redis
):Donc, ce que vous devez faire est de mapper le
/data
dossier du conteneur vers un emplacement externe (où l'utilisateur non root, ici: 1007, a un accès en écriture, comme/tmp
sur la machine hôte), par exemple:Il s'agit donc d'une mauvaise configuration de l'image Docker officielle (qui devrait écrire dans
/tmp
non/data
) qui produit cette "bombe à retardement" que vous ne rencontrerez probablement qu'en production ... du jour au lendemain pendant un week-end de vacances particulièrement calme: /la source
pour moi
et je recharge mon mac, ça marche
la source
J'ai rencontré ce problème lorsque je travaillais sur un serveur avec de l'espace disque AFS car mon jeton d'authentification avait expiré, ce qui a donné des
Permission Denied
réponses lorsque le serveur redis a tenté de sauvegarder. J'ai résolu cela en rafraîchissant mon jeton:kinit USERNAME_HERE -l 30d && aklog
la source
Dans le cas où vous utilisez docker / docker-compose et que vous souhaitez empêcher redis d'écrire dans un fichier, vous pouvez créer une configuration redis et monter dans un conteneur
docker.compose.override.yml
Vous pouvez télécharger la configuration par défaut à partir d' ici
dans le fichier redis.conf assurez-vous de commenter ces 3 lignes
myou peut voir plus de solutions pour supprimer les données persistantes ici
la source
Dans mon cas, cela s'est produit parce que je viens d'installer en
redis
utilisant la méthode rapide. Donc redis ne fonctionne pas en tant que root. J'ai pu résoudre ce problème en suivant les instructions de laInstalling Redis more properly
section de leur Guide de démarrage rapide . Après cela, le problème a été résolu etredis
s'exécute maintenant en tant que root. Vérifiez-le.la source
Après m'être cogné la tête à travers tant de questions SO enfin - pour moi, la réponse d'Axel Advento a fonctionné mais avec quelques étapes supplémentaires - j'étais toujours confronté aux problèmes de permission.
J'ai dû changer d'utilisateur pour
redis
, créer un nouveau répertoire dans son répertoire d'origine, puis le définir comme répertoire de redis.la source
Dans mon cas, c'était lié à l'espace libre sur le disque. (vous pouvez le vérifier avec la
df -h
commande bash) lorsque je libère de l'espace, cette erreur a disparu.la source
Si vous exécutez Redis localement sur une machine Windows, essayez de "exécuter 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 restreint les autorisations par défaut. Comme il se doit.
Cependant, n'exécutez 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 le remède. Un scénario probable est que vous avez placé Redis dans un dossier qui ne dispose pas de droits d'écriture et que le fichier DB est par conséquent stocké au même emplacement.
Vous pouvez résoudre ce problème en ouvrant le
redis.windows.conf
et pour rechercher la configuration suivante:Passez
dir ./
à un chemin pour lequel vous disposez d'autorisations de lecture / écriture régulièresVous pouvez également déplacer le dossier Redis dans son intégralité vers un dossier dont vous savez qu'il dispose des autorisations appropriées.
la source
Pour moi, c'était juste un problème d'autorisations sur le dossier de données redis persistant. Je lui ai donné un:
Et ça marche! Il est peut-être tôt pour dire que cela résoudra le problème. Parce que je soupçonne également que redis ne s'exécute pas en tant que root, je dois donc inspecter mon dockerFile pour en savoir plus.
la source
Vérifiez votre journal Redis avant de prendre toute mesure. Certaines des solutions de ce fil peuvent effacer vos données Redis, alors faites attention à ce que vous faites.
Dans mon cas, la machine manquait de RAM . Cela peut également se produire lorsqu'il n'y a plus d'espace disque disponible sur l'hôte.
la source
Veuillez noter que cette erreur apparaît lorsque votre serveur est attaqué. Je viens de découvrir que redis ne parvient pas à écrire dans '/etc/cron.d/web' où, après correction des autorisations, un nouveau fichier composé d'un algorithme d'exploration de données avec quelques options de masquage a été ajouté.
la source
la source
Comme l'a souligné @Chris, le problème est susceptible de manquer 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 qu'il y ait suffisamment de RAM pour Redis et d'autres services, nous avons réduit
innodb_buffer_pool_size
sur MySQL.la source
Dans mon cas, la raison était un espace libre très faible sur le disque (seulement 35 Mo). J'ai fait ce qui suit -
Supprimer le fichier de vidage redis (si les données existantes ne sont pas nécessaires)
sudo rm /var/lib/redis/*
Supprimer toutes les clés de toutes les bases de données existantes
sudo redis-cli flushall
la source
vous devez chmod et chown le nouveau dossier
chown -R redis et chmod ...
la source