MISCONF Redis est configuré pour enregistrer des instantanés RDB
Pendant les écritures sur Redis (SET foo bar), le message d'erreur suivant s'affiche:
MISCONF Redis est configuré pour enregistrer les instantanés de la base de données de résolution, mais est actuellement pas capable de persister sur le disque. Les commandes pouvant modifier le jeu de données sont désactivée. S'il vous plaît vérifier les journaux Redis pour plus de détails sur l'erreur.
En gros, je comprends que le problème est que redis n'est pas en mesure de sauvegarder des données sur le disque, mais je ne sais pas comment nous en débarrasser.
Aussi la question suivante a le même problème, il a été abandonné il y a longtemps sans réponse et probablement aucune tentative de le résoudre.
Si vous rencontrez l'erreur et que certaines données importantes ne peuvent pas être ignorées sur l'instance redis en cours d'exécution (problèmes d'autorisations pour le fichier rdb ou son répertoire de manière incorrecte, ou manque d'espace disque), vous pouvez toujours rediriger le fichier rdb pour l'écrire 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 pouvez 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 a réussi ou une erreur s'est produite). Après cela, vous pouvez maintenant commencer à sauvegarder le fichier rdb généré dans un endroit sûr.
Vous pouvez l'arrêter en essayant de sauvegarder 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 si l’opération bgsave a échoué en premier lieu.
Il peut y avoir des erreurs lors du processus bgsave en raison d'une mémoire insuffisante. Essayez ceci (à partir de la FAQ de sauvegarde de Redis Background)
echo 'vm.overcommit_memory = 1' >> /etc/sysctl.conf
sysctl vm.overcommit_memory=1
Juste trop bref sur la réponse. terminal ouvert et tapez les commandes suivantes
redis-cli
et maintenant tapez
config set stop-writes-on-bgsave-error no
si vous travaillez sur une machine Linux, vérifiez également les autorisations de fichier et de dossier de la base de données.
La base de données et son chemin peuvent être obtenus via:
dans redis-cli:
CONFIG GET dir
CONFIG GET nom_fichier
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. De plus, normalement, redis-server s’exécute en tant qu’utilisateur redis, il est donc agréable de donner à l’utilisateur redis la propriété du dossier en exécutant Sudo chown -R redis:redis /path/to/rdb/folder. Cela a été précisé dans la réponse ici .
Merci à tous d'avoir vérifié le problème, apparemment l'erreur a été générée pendant 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.
Cette erreur est due à l'échec de BGSAVE. Au cours de BGSAVE, Redis demande à un processus enfant de sauvegarder les données sur le disque. Bien que la cause 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), il arrive souvent que BGAVE échoue car le fork ne peut pas allouer de mémoire. Plusieurs fois, la fourchette n'alloue pas de mémoire (bien que la machine dispose de suffisamment de mémoire RAM disponible) en raison d'une optimisation conflictuelle par le système d'exploitation.
Comme on peut le lire dans Redis FAQ :
Le schéma de sauvegarde en arrière-plan Redis repose sur la sémantique de fork de la copie sur écriture 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 base de données sur le disque et se ferme finalement. En théorie, l'enfant devrait utiliser autant de mémoire que le parent, mais, grâce à la sémantique de copie sur écriture mise en œuvre par la plupart des systèmes d'exploitation modernes, les processus parent et enfant partageront les pages de mémoire communes. Une page ne sera dupliquée que si elle change dans l'enfant ou dans le parent. Étant donné qu'en théorie, toutes les pages peuvent changer pendant la sauvegarde du processus enfant, Linux ne peut pas savoir à l'avance combien de mémoire il prendra. Par conséquent, si le paramètre de surcommit_memory est défini sur zéro, fork échouera à moins qu'il y ait autant d'espace libre RAM si nécessaire pour vraiment dupliquer toutes les pages de la mémoire parent, si bien que si vous avez un jeu de données Redis de 3 Go et seulement 2 Go de mémoire disponible, il échouera.
Définir surcommit_memory sur 1 indique que Linux doit se détendre et effectuer le fork de manière plus optimiste, ce qui est bien ce que vous souhaitez pour Redis.
Redis n'a pas besoin de autant de mémoire que le système d'exploitation ne le pense pour écrire sur le disque, il est donc possible que la fourche échoue de façon préemptive.
Pour résoudre cela, 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
Démarrer le serveur Redis dans un répertoire où Redis dispose d'autorisations 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'emplacement 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 autorisations appropriées pour créer le fichier dump.rdb.
Pour aggraver les choses, redis ne vous autorisera probablement pas non plus à arrêter le serveur tant qu'il ne sera pas en mesure de créer le fichier rdb afin de garantir la sauvegarde 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 le dossier de votre projet ou dans tout dossier dans lequel les utilisateurs non root ont le droit de sauvegarder. Ensuite, exécutez 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 autorisations pour le répertoire afin que redis puisse y écrire. stackoverflow pour savoir comment faire cela).
Vous devriez maintenant pouvoir fermer le serveur Redis. Notez que nous avons codé le chemin en dur. Le codage en dur est rarement une bonne pratique et je recommande vivement de démarrer le serveur Redis à partir du répertoire de votre projet et de modifier le dir key back to./ `.
CONFIG SET dir "./"
BGSAVE
Ainsi, lorsque vous aurez 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.
Une solution plus permanente pourrait consister à regarder dans /etc/redis/redis.conf autour des lignes 200 à 250, il existe des paramètres pour les fonctionnalités rdb, qui ne faisaient pas partie de redis à l'époque 2.x.
notamment
dir ./
peut être changé en
dir /home/someuser/redislogfiledirectory
ou vous pouvez commenter toutes les lignes de sauvegarde sans vous soucier de la persistance. (Voir les commentaires dans /etc/redis/redis.conf)
De plus, n'oubliez pas
service redis-server stop
service redis-server start
S'il vous plaît vérifier ici .
$ redis-cli
> config set stop-writes-on-bgsave-error no
Cela peut aider à résoudre ce problème.
Avait rencontré cette erreur et était capable de comprendre à partir du journal que l'erreur est due à un manque d'espace disque. Toutes les données insérées dans mon cas n'étaient plus nécessaires. Alors j'ai essayé de FLUSHALL. Le processus redis-rdb-bgsave étant en cours d’exécution, il ne permettait pas non plus de FLUSHER les données. J'ai suivi les étapes ci-dessous et j'ai pu continuer.
- Se connecter au client redis
- Execute config set stop-writes-on-bgsave-error no
- Execute_FLUSHALL(les données stockées n'étaient pas nécessaires)
- Execute config set stop-writes-on-bgsave-error yes
Le processus redis-rdb-bgsave ne fonctionnait plus après les étapes ci-dessus.
toutes ces réponses n'expliquent pas la raison pour laquelle la sauvegarde de la base de données rdb a échoué.
comme ce fut 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:juin 18 13:23:07 10-10-88-16 noyau: [28152358.208108] Processus tué 28416 (serveur redis) total-vm: 7660204kB, anon-rss: 2285492kB, fichier-rss: 0ko
c'est ça! ce processus (redis save rdb) est tué par tueur de MOO
fait référence:
FWIW, je me suis heurté à cela et la solution consistait simplement à ajouter 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
De nos jours, les problèmes d'accès en écriture de Redis qui transmettent ce message d'erreur au client sont réapparus dans les conteneurs officiels redis docker.
Redis de l'image redis officielle tente d'écrire le fichier .rdb dans le dossier containers /data, ce qui est plutôt dommage, car il s'agit d'un dossier appartenant à la racine et non persistant. emplacement également (les données qui y sont écrites disparaîtront si votre conteneur/pod tombe en panne).
Ainsi, après une heure d'inactivité, si vous avez exécuté votre conteneur redis en tant qu'utilisateur non root (par exemple, docker run -u 1007 plutôt que par défaut docker run -u 0), vous obtiendrez un message d'erreur bien détaillé dans votre serveur journal (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
Vous devez donc mapper le dossier /data du conteneur sur un emplacement externe (où l'utilisateur non root, ici: 1007, dispose d'un accès en écriture, tel que /tmp sur 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 officielle du docker (qui devrait écrire à /tmp pas /data) qui produit cette "bombe à retardement" que vous ne rencontrerez probablement que dans la production ... du jour au lendemain. Week-end de vacances tranquille: /
J'ai rencontré ce problème alors que je travaillais sur un serveur disposant d'un espace disque AFS car mon jeton d'authentification avait expiré, ce qui a généré des réponses Permission Denied lorsque le serveur Redis a tenté de sauvegarder. J'ai résolu ceci en rafraîchissant mon jeton:
kinit USERNAME_HERE -l 30d && aklog
Je faisais face au même problème, principalement à cause de la consommation de mémoire vive (RAM) de Redis . Ma machine EC2 disposait de 8 Go de RAM (environ 7,4 disponibles).
Lorsque mon programme fonctionnait, l'utilisation de RAM atteignait 7,2 Go, ce qui laissait à peine environ 100 Mo dans RAM. Cela déclenchait généralement le MISCONF Redis error ...
Vous pouvez déterminer la consommation RAM à l'aide de la commande htop. Recherchez l'attribut Mem après l'exécution de la commande htop. Si la consommation est élevée (comme dans mon cas, elle était de 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, utiliser config set stop-writes-on-bgsave-error no sera un sinistre pour le serveur et pourrait entraîner en perturbant d'autres services en cours d'exécution sur le serveur (le cas échéant). Il vaut donc mieux éviter la commande config et METTEZ À JOUR VOTRE MACHINE REDIS .
Pour votre information: 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, vérifiez si un autre service est exécuté sur votre serveur/machine/instance et arrêtez-le s'il n'est pas nécessaire. Pour vérifier tous les services en cours d'exécution 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 au moins avertir l'utilisateur avant d'utiliser de telles commandes. Et comme @Rodrigo l'a mentionné dans son commentaire: "Il ne semble pas que ce soit cool d'ignorer les erreurs."
vous devez chmod et chown le nouveau dossier
chown -R redis et chmod ...
Si vous exécutez Redis localement sur une machine Windows, essayez de "s'exécuter en tant qu'administrateur" et vérifiez si cela fonctionne. Avec moi, le problème était que Redis se trouvait dans le dossier "Program Files", ce qui restreignait les autorisations par défaut. Comme il se doit.
Cependant, ne lance pas automatiquement Redis en tant qu'administrateur Vous ne voulez pas lui accorder plus de droits que ce qu'il est supposé avoir. Vous voulez résoudre ceci 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 ne disposant pas de droits en écriture et que, par conséquent, le fichier de base de données est stocké au 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 ./
Remplacez dir ./ par un chemin pour lequel vous disposez des autorisations de lecture/écriture habituelles pour
Vous pouvez également simplement déplacer le dossier Redis dans son intégralité vers un dossier disposant des autorisations appropriées.
Dans mon cas, la raison était très peu d'espace libre sur le disque (seulement 35 Mo). J'ai fait ce qui suit -
- Arrêt de tous les processus liés à Redis
- Supprimez certains fichiers sur le disque pour libérer suffisamment d'espace libre
Supprimer le fichier redis dump (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- redémarrez toutes les tâches de céleri et consultez les journaux correspondants pour détecter tout problème éventuel
Si vous utilisez docker/docker-compose et souhaitez empêcher l’écriture de fichiers redis dans un fichier, vous pouvez créer une configuration redis et la 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 depuis 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 était lié à l’espace disque disponible. (vous pouvez le vérifier avec la commande df -h bash) lorsque je libère de l'espace, cette erreur a disparu.
pour moi
config set stop-writes-on-bgsave-error no
et je recharge mon mac, ça marche
Moi aussi, je faisais face au même problème. Les deux réponses (la plus votée et la plus acceptée) donnent simplement un correctif temporaire pour la même chose.
De plus, le config set stop-writes-on-bgsave-error no est un moyen horrible de dépasser cette erreur, puisque cette option empêche les redis de notifier que les écritures ont été arrêtées et de continuer sans écrire les données dans un instantané. C'est simplement en ignorant cette erreur . Report this
En ce qui concerne la définition de dir dans config dans redis-cli, une fois que vous aurez redémarré le service redis, cette opération sera également effacée et la même erreur réapparaîtra. La valeur par défaut de dir dans redis.conf est ./ et si vous démarrez redis en tant qu'utilisateur root, alors ./ est / auquel les autorisations d'écriture ne sont pas accordées, d'où l'erreur.
La meilleure méthode consiste à définir le paramètre dir dans le fichier redis.conf et à définir les autorisations appropriées pour ce répertoire. La plupart des distributions debian l’auront en /etc/redis/redis.conf
Comme l'a souligné @Chris, le problème risque de manquer de mémoire. Nous avons commencé à en faire l'expérience lorsque nous avons trop alloué RAM à MySQL (innodb_buffer_pool_size).
Pour nous assurer qu'il y a suffisamment de RAM pour Redis et d'autres services, nous avons réduit innodb_buffer_pool_size sur MySQL.