During writes to Redis ( SET foo bar ) I am getting the following error:
MISCONF Redis is configured to save RDB snapshots, but is currently not able to persist on disk. Commands that may modify the data set are disabled. Please check Redis logs for details about the error.
Basically I understand that the problem is that redis is not able to save data on the disk, but have no idea how to get rid of the problem.
Also the following question has the same problem, it is abandoned long time ago with no answers and most probably no attempts to solve the problem.
This question is related to
redis
As pointed out by @Chris the problem is likely to to low memory. We started experiencing it when we allocated too much RAM to MySQL (innodb_buffer_pool_size).
To ensure there's enough RAM for Redis and other services we reduced innodb_buffer_pool_size on MySQL.
FWIW, I ran into this and the solution was to simply add a swapfile to the box. I used this method: https://www.digitalocean.com/community/tutorials/how-to-add-swap-on-ubuntu-14-04
Thanks everyone for checking the problem, apparently the error was produced during bgsave.
For me, typing config set stop-writes-on-bgsave-error no in a shell and restarting Redis solved the problem.
Restart your redis server.
brew services restart redis.sudo service redis restart / sudo systemctl restart redisservices.msc, Enter -> Search for Redis then click on restart. I personally had this issue after upgrading redis with Brew (brew upgrade).
After rebooting the laptop, it immediately worked.
Please, be aware, that this error appears when your server is under attack. Just found that redis fails to write to '/etc/cron.d/web' where after correcting of permissions, new file consisting of mining algorithm with some hiding options was added.
There might be errors during the bgsave process due to low memory. Try this (from redis background save FAQ)
echo 'vm.overcommit_memory = 1' >> /etc/sysctl.conf
sysctl vm.overcommit_memory=1
# 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
for me
config set stop-writes-on-bgsave-error no
and I reload my mac, it works
I too was facing the same issue. Both the answers (the most upvoted one and the accepted one) just give a temporary fix for the same.
Moreover, the config set stop-writes-on-bgsave-error no is a horrible way to over look this error, since what this option does is stop redis from notifying that writes have been stopped and to move on without writing the data in a snapshot. This is simply ignoring this error.
Refer this
As for setting dir in config in redis-cli, once you restart the redis service, this shall get cleared too and the same error shall pop up again. The default value of dir in redis.conf is ./ , and if you start redis as root user, then ./ is / to which write permissions aren't granted, and hence the error.
The best way is to set the dir parameter in redis.conf file and set proper permissions to that directory. Most of the debian distributions shall have it in /etc/redis/redis.conf
In case you are using docker/docker-compose and want to prevent redis from writing to file, you can create a redis config and mount into a container
docker.compose.override.yml
redis:¬
volumes:¬
- ./redis.conf:/usr/local/etc/redis/redis.conf¬
ports:¬
- 6379:6379¬
You can download the default config from here
in the redis.conf file make sure you comment out these 3 lines
save 900 1
save 300 10
save 60 10000
myou can view more solutions for removing the persistent data here
In my case it was related to disk free space. (you can check it with df -h bash command) when I free some space this error disappeared.
In my case it happened because I just installed redis using the quick way. So redis is not running as root.
I was able to solve this problem by following the instructions under the Installing Redis more properly section of their Quick Start Guide. After doing so, the problem was solved and redis is now running as root. Check it out.
all of those answers do not explain the reason why the rdb save failed.
as my case, I checked the redis log and found:
14975:M 18 Jun 13:23:07.354 # Background saving terminated by signal 9
run the following command in terminal:
sudo egrep -i -r 'killed process' /var/log/
it display:
/var/log/kern.log.1:Jun 18 13:23:07 10-10-88-16 kernel: [28152358.208108] Killed process 28416 (redis-server) total-vm:7660204kB, anon-rss:2285492kB, file-rss:0kB
that is it! this process(redis save rdb) is killed by OOM killer
refers:
I faced the similar issue, the main reason behind this was the memory(RAM) consumption by redis. My EC2 machine had 8GB RAM(arounf 7.4 available for consumption)
When my program was running the RAM usage went upto 7.2 GB leaving hardly ~100MB in RAM , this generally triggers the MISCONF Redis error ...
You can determine the RAM consumption using the htop command. Look for the Mem attribute after running htop command. If it shows high consumtion (like in my case it was 7.2GB/7.4GB) It's better to upgrade the instance's with larger Memory.
In this scenario using config set stop-writes-on-bgsave-error no will be a disaster for the server and may result in disrupting other services running on the server(if any). So, it better to avoid the config command and UPGRADE YOUR REDIS MACHINE.
FYI: You may need to install htop to make this work : sudo apt-get install htop
One more solution to this can be some other RAM heavy service running on your system, check for other service running on your server/machine/instance and stop it if its not necessary. To check all the services running on your machine use service --status-all
And a suggestion for people directly pasting the config command , please do reasearch a bit and atleast warn the user before using such commands. And as @Rodrigo mentioned in his comment : "It does not look cool to ignore the errors."
---UPDATE---
YOu can also configure maxmemory and maxmemory-policy to define the behavior of Redis when a specific limit of memory is reached.
For example, if I want to keep the memory limit of 6GB and delete the least recently used keys from the DB to make sure that redis mem usage do not exceed 6GB, then we can set these two parameters (in redis.conf or CONFIG SET command):
maxmemory 6gb
maxmemory-policy allkeys-lru
There are a lot of other values which you can set for these two parameters you can read about this from here: https://redis.io/topics/lru-cache
in case you are working on a linux machine, also recheck the file and folder permissions of the database.
The db and the path to it can be obtained via:
in redis-cli:
CONFIG GET dir
CONFIG GET dbfilename
and in the commandline ls -l. The permissions for the directory should be 755, and those for the file should be 644. Also, normally redis-server executes as the user redis, therefore its also nice to give the user redis the ownership of the folder by executing sudo chown -R redis:redis /path/to/rdb/folder. This has been elaborated in the answer here.
In my case, the reason was very low free space in disk (only 35 Mb). I did the following -
Delete redis dump file (if existing data not needed)
sudo rm /var/lib/redis/*
Delete all the keys of all the existing databases
sudo redis-cli flushall
Using redis-cli, you can stop it trying to save the snapshot:
config set stop-writes-on-bgsave-error no
This is a quick workaround, but if you care about the data you are using it for, you should check to make sure why bgsave failed in first place.
If you're running MacOS and have recently upgraded to Catalina, you may need to run brew services restart redis as suggested in this issue.
This error occurs because of BGSAVE being failed. During BGSAVE, Redis forks a child process to save the data on disk. Although exact reason for failure of BGSAVE can be checked from logs (usually at /var/log/redis/redis-server.log on linux machines) but a lot of the times BGAVE fails because the fork can't allocate memory. Many times the fork fails to allocate memory (although the machine has enough RAM available) because of a conflicting optimization by the OS.
As can be read from Redis FAQ:
Redis background saving schema relies on the copy-on-write semantic of fork in modern operating systems: Redis forks (creates a child process) that is an exact copy of the parent. The child process dumps the DB on disk and finally exits. In theory the child should use as much memory as the parent being a copy, but actually thanks to the copy-on-write semantic implemented by most modern operating systems the parent and child process will share the common memory pages. A page will be duplicated only when it changes in the child or in the parent. Since in theory all the pages may change while the child process is saving, Linux can't tell in advance how much memory the child will take, so if the overcommit_memory setting is set to zero fork will fail unless there is as much free RAM as required to really duplicate all the parent memory pages, with the result that if you have a Redis dataset of 3 GB and just 2 GB of free memory it will fail.
Setting overcommit_memory to 1 says Linux to relax and perform the fork in a more optimistic allocation fashion, and this is indeed what you want for Redis.
Redis doesn't need as much memory as the OS thinks it does to write to disk, so may pre-emptively fail the fork.
To Resolve this, you can:
Modify /etc/sysctl.conf and add:
vm.overcommit_memory=1
Then restart sysctl with:
On FreeBSD:
sudo /etc/rc.d/sysctl reload
On Linux:
sudo sysctl -p /etc/sysctl.conf
Check your Redis log before taking any action. Some of the solutions in this thread may erase your Redis data, so be careful about what you are doing.
In my case, the machine was running out of RAM. This also can happen when there is no more free disk space on the host.
A more permanent fix might be to look in /etc/redis/redis.conf around lines 200-250 there are settings for the rdb features, that were not a part of redis back in the 2.x days.
notably
dir ./
can be changed to
dir /home/someuser/redislogfiledirectory
or you could comment out all the save lines, and not worry about persistence. (See the comments in /etc/redis/redis.conf)
Also, don't forget
service redis-server stop
service redis-server start
Had encountered this error and was able to figure out from log that the error is because of the disk space not being enough. All the data that was inserted in my case was not needed any longer. So I tried to FLUSHALL. Since redis-rdb-bgsave process was running, it was not allowing to FLUSH the data also. I followed below steps and was able to continue.
The process redis-rdb-bgsave was no longer running after the above steps.
I hit this problem while working on a server with AFS disk space because my authentication token had expired, which yielded Permission Denied responses when the redis-server tried to save. I solved this by refreshing my token:
kinit USERNAME_HERE -l 30d && aklog
For me it was just a problem of permissions on the persistent redis data folder. I gave it a:
chmod 777 -Rf data/
And it's works ! May be it's early to say it's resolve the issue. Because I also suspect that redis is not executing as root so I need to inspect my dockerFile to figure out more.
Nowadays the Redis write-access problems that give this error message to the client re-emerged in the official redis docker containers.
Redis from the official redis image tries to write the .rdb file in the containers /data folder, which is rather unfortunate, as it is a root-owned folder and it is a non-persistent location too (data written there will disappear if your container/pod crashes).
So after an hour of inactivity, if you have run your redis container as a non-root user (e.g. docker run -u 1007 rather than default docker run -u 0), you will get a nicely detailed error msg in your server log (see 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
So what you need to do is to map container's /data folder to an external location (where the non-root user, here: 1007, has write access, such as /tmp on the host machine), e.g:
docker run --rm -d --name redis -p 6379:6379 -u 1007 -v /tmp:/data redis
So it is a misconfiguration of the official docker image (which should write to /tmp not /data) that produces this "time bomb" that you will most likely encounter only in production... overnight over some particularly quiet holiday weekend :/
I know this thread is slightly older, but here's what worked for me when I got this error earlier, knowing I was nowhere near memory limit- both answers were found above.
Hopefully this could help someone in the future if they need it.
Again- unsure how the permissions on the DIR folder got changed, but I'm assuming CHMOD back to 755 and restarting redis-server took care of it as I was able to ping redis server afterwards.
Also- to note, redis did have ownership of the dbfilename and DIR folder.
you must chmod and chown the new folder
chown -R redis and chmod ...
On redis.conf line ~235 let's try to change config like this
- stop-writes-on-bgsave-error yes
+ stop-writes-on-bgsave-error no
The answers above will definitely solve your problem, but here's what's actually going on:
The default location for storing the rdb.dump file is ./ (denoting current directory). You can verify this in your redis.conf file. Therefore, the directory from where you start the redis server is where a dump.rdb file will be created and updated.
It seems you have started running the redis server in a directory where redis does not have the correct permissions to create the dump.rdb file.
To make matters worse, redis will also probably not allow you to shut down the server either until it is able to create the rdb file to ensure the proper saving of data.
To solve this problem, you must go into the active redis client environment using redis-cli and update the dir key and set its value to your project folder or any folder where non-root has permissions to save. Then run BGSAVE to invoke the creation of the dump.rdb file.
CONFIG SET dir "/hardcoded/path/to/your/project/folder"
BGSAVE
(Now, if you need to save the dump.rdb file in the directory that you started the server in, then you will need to change permissions for the directory so that redis can write to it. You can search stackoverflow for how to do that).
You should now be able to shut down the redis server. Note that we hardcoded the path. Hardcoding is rarely a good practice and I highly recommend starting the redis server from your project directory and changing the dir key back to./`.
CONFIG SET dir "./"
BGSAVE
That way when you need redis for another project, the dump file will be created in your current project's directory and not in the hardcoded path's project directory.
After banging my head through so many SO questions finally -
for me @Axel Advento' s answer worked but with few extra steps -
I was still facing the permission issues.
I had to switch user to redis, create a new dir in it's home dir and then set it as redis's dir.
sudo su - redis -s /bin/bash
mkdir redis_dir
redis-cli CONFIG SET dir $(realpath redis_dir)
exit # to logout from redis user (optional)
If you are running Redis locally on a windows machine, try to "run as administrator" and see if it works. With me, the problem was that Redis was located in the "Program Files" folder, which restricts permissions by default. As it should.
However, do not automatically run Redis as an administrator You don't want to grant it more rights that it is supposed to have. You want to solve this by the book.
So, we have been able to quickly identify the problem by running it as an administrator, but this is not the cure. A likely scenario is that you have put Redis in a folder that doesn't have write rights and as a consequence the DB file is stored in that same location.
You can solve this by opening the redis.windows.conf and to search for the following configuration:
# 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 ./
Change dir ./ to a path you have regular read/write permissions for
You could also just move the Redis folder in it's entirety to a folder you know has the right permissions.
Source: Stackoverflow.com