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

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.

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 rdbfichier ou son répertoire de manière incorrecte ou manque d'espace disque), vous pouvez toujours rediriger le rdbfichier pour qu'il soit écrit ailleurs.

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 BGSAVEcommande pour vous assurer que les données seront écrites dans le rdbfichier. Assurez-vous que lorsque vous exécutez INFO persistence, bgsave_in_progressest déjà 0et rdb_last_bgsave_statusest ok. Après cela, vous pouvez maintenant commencer à sauvegarder le rdbfichier généré dans un endroit sûr.

À l'aide de redis-cli, vous pouvez l'arrêter en essayant d'enregistrer l'instantané:

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

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.

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)

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

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.logsur 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 :

Le schéma d'enregistrement en arrière-plan de Redis repose sur la sémantique de copie sur écriture de fork dans les systèmes d'exploitation modernes: les fourches Redis (créent un processus enfant) qui est une copie exacte du parent. Le processus enfant vide la base de données 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 fait grâce à la sémantique de copie sur écriture implémentée par la plupart des systèmes d'exploitation modernes, le processus parent et enfant partagera les pages de mémoire communes. Une page ne sera dupliquée que lorsqu'elle change chez l'enfant ou chez le parent. Étant donné qu'en théorie, toutes les pages peuvent changer pendant l'enregistrement du processus enfant, Linux ne peut pas dire à l'avance la quantité de mémoire que l'enfant prendra, donc si le paramètre overcommit_memory est défini sur zéro, fork échouera à moins qu'il y ait autant de RAM libre que nécessaire pour vraiment dupliquer toutes les pages de mémoire parent,

Mettre overcommit_memory à 1 indique à Linux de détendre et d'effectuer le fork d'une manière d'allocation plus optimiste, et c'est en effet ce que vous voulez pour 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.confet ajoutez:

vm.overcommit_memory=1

Redémarrez ensuite sysctl avec:

Sur FreeBSD:

sudo /etc/rc.d/sysctl reload

Sous Linux:

sudo sysctl -p /etc/sysctl.conf

Redémarrez votre serveur redis.

• macOS (infusion) : brew services restart redis.
• Linux: sudo service redis restart /sudo systemctl restart redis
• Windows: Windows + R-> Tapez services.msc, Enter-> Rechercher Redispuis cliquez sur restart.

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é.

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:

CONFIG GET dir

CONFIG GET dbfilename

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'utilisateur redis, il est donc également agréable de donner à l'utilisateur redisla propriété du dossier en l'exécutant sudo chown -R redis:redis /path/to/rdb/folder. Ceci a été développé dans la réponse ici .

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 noun shell et redémarrer Redis a résolu le problème.

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.dumpfichier est ./(indiquant le répertoire actuel). Vous pouvez le vérifier dans votre redis.confdossier. Par conséquent, le répertoire à partir duquel vous démarrez le serveur redis est l'endroit où un dump.rdbfichier 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.rdbfichier.

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-clila dirclé 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 ensuite BGSAVEpour appeler la création du dump.rdbfichier.

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 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. / `.

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 de projet du chemin codé en dur.

Si vous utilisez MacOS et avez récemment mis à niveau vers Catalina, vous devrez peut-être exécuter brew services restart rediscomme suggéré dans ce problème .

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.

1. Connectez-vous au client redis
2. Exécuter le jeu de configuration stop-write-on-bgsave-error no
3. Exécuter FLUSHALL (les données stockées n'étaient pas nécessaires)
4. Exécuter le jeu de configuration stop-write-on-bgsave-error yes

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

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 htopcommande. 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'utilisation config set stop-writes-on-bgsave-error nosera 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, utilisezservice --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 maxmemoryet maxmemory-policydé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):

maxmemory 6gb
maxmemory-policy allkeys-lru

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

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

dir ./

peut être changé en

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)

N'oubliez pas non plus

service redis-server stop
service redis-server start

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é:

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

exécutez la commande suivante dans le terminal:

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

il affiche:

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

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

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

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 noc'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 ceci

Quant à la configuration dirdans configredis-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 de dirin redis.confest ./, 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 dirparamè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

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 redisconteneurs Docker officiels .

Redis à partir de l' redisimage officielle essaie d'écrire le fichier .rdb dans le /datadossier 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 redisconteneur en tant qu'utilisateur non root (par exemple docker run -u 1007plutôt que par défaut docker run -u 0), vous obtiendrez un message d'erreur bien détaillé dans votre journal de serveur (voir docker logs redis):

1:M 29 Jun 2019 21:11:22.014 * 1 changes in 3600 seconds. Saving...
1:M 29 Jun 2019 21:11:22.015 * Background saving started by pid 499
499:C 29 Jun 2019 21:11:22.015 # Failed opening the RDB file dump.rdb (in server root dir /data) for saving: Permission denied
1:M 29 Jun 2019 21:11:22.115 # Background saving error

Donc, ce que vous devez faire est de mapper le /datadossier du conteneur vers un emplacement externe (où l'utilisateur non root, ici: 1007, a un accès en écriture, comme /tmpsur la machine hôte), par exemple:

docker run --rm -d --name redis -p 6379:6379 -u 1007 -v /tmp:/data redis

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: /

pour moi

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

et je recharge mon mac, ça marche

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 Deniedré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

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

  redis:¬
      volumes:¬
        - ./redis.conf:/usr/local/etc/redis/redis.conf¬
      ports:¬
        - 6379:6379¬

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

save 900 1
save 300 10
save 60 10000

myou peut voir plus de solutions pour supprimer les données persistantes ici

Dans mon cas, cela s'est produit parce que je viens d'installer en redisutilisant 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 la Installing Redis more properlysection de leur Guide de démarrage rapide . Après cela, le problème a été résolu et rediss'exécute maintenant en tant que root. Vérifiez-le.

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.

sudo su - redis -s /bin/bash
mkdir redis_dir
redis-cli CONFIG SET dir $(realpath redis_dir)
exit # to logout from redis user (optional)

Dans mon cas, c'était lié à l'espace libre sur le disque. (vous pouvez le vérifier avec la df -hcommande bash) lorsque je libère de l'espace, cette erreur a disparu.

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.confet pour rechercher 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 ./

Passez dir ./à un chemin pour lequel vous disposez d'autorisations de lecture / écriture régulières

Vous pouvez également déplacer le dossier Redis dans son intégralité vers un dossier dont vous savez qu'il dispose des autorisations appropriées.

Pour moi, c'était juste un problème d'autorisations sur le dossier de données redis persistant. Je lui ai donné un:

chmod 777 -Rf data/

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.

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.

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é.

# on redis 6.0.4 
# if show error 'MISCONF Redis is configured to save RDB snapshots'
# Because redis doesn't have permissions to create dump.rdb file
sudo redis/bin/redis-server 
sudo redis/bin/redis-cli

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_sizesur MySQL.

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. Supprimez certains fichiers sur le disque pour libérer de l'espace

3. Supprimer le fichier de vidage 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

vous devez chmod et chown le nouveau dossier

chown -R redis et chmod ...