Redis error misconf redis is configured to save rdb snapshots - Исправление ошибок и поиск оптимальных решений проблем

Restart your redis server.

macOS (brew): brew services restart redis.
Linux: sudo service redis restart / sudo systemctl restart redis
Windows: Windows + R -> Type services.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.

answered Dec 18, 2019 at 12:27

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.

answered Jan 31, 2014 at 15:54

思考zhe思考zhe

5,1972 gold badges12 silver badges9 bronze badges

In case you encounter the error and some important data cannot be discarded on the running redis instance (problems with permissions for the rdb file or its directory incorrectly, or running out of disk space), you can always redirect the rdb file to be written somewhere else.

Using redis-cli, you can do something like this:

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

After this, you might want to execute a BGSAVE command to make sure that the data will be written to the rdb file. Make sure that when you execute INFO persistence, bgsave_in_progress is already 0 and rdb_last_bgsave_status is ok. After that, you can now start backing up the generated rdb file somewhere safe.

answered Oct 30, 2013 at 3:41

Axel AdventoAxel Advento

2,9753 gold badges24 silver badges32 bronze badges

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

answered Dec 13, 2013 at 22:37

ChrisChris

1,5121 gold badge12 silver badges19 bronze badges

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

answered Apr 15, 2018 at 6:42

BhindiBhindi

1,33311 silver badges16 bronze badges

In my case, it was just the privileges that I needed to allow for Redis to accept the incoming request.

So I restarted the Redis service via Homebrew brew services stop redis and brew services start redis and run the Redis server locally redis-server. The command prompt asked me to allow the incoming request and it started working.

answered May 16, 2022 at 10:23

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.

answered Jul 13, 2014 at 18:26

smilee89smilee89

5035 silver badges9 bronze badges

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.

answered Nov 11, 2019 at 5:30

FushFush

2,41920 silver badges19 bronze badges

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.

answered Oct 25, 2013 at 4:45

Salvador DaliSalvador Dali

209k145 gold badges690 silver badges749 bronze badges

Start Redis Server in a directory where Redis has write permissions

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.

answered Sep 23, 2017 at 19:57

Govind RaiGovind Rai

13.6k9 gold badges68 silver badges81 bronze badges

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.

Login to redis client
Execute config set stop-writes-on-bgsave-error no
Execute FLUSHALL (Data stored was not needed)
Execute config set stop-writes-on-bgsave-error yes

The process redis-rdb-bgsave was no longer running after the above steps.

answered Sep 4, 2018 at 7:09

RCKRCK

3112 silver badges4 bronze badges

$ redis-cli

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

According to Redis documentation, this is recommended only if you don’t have RDB snapshots enabled or if you don’t care about data persistence in the snapshots.

«By default Redis will stop accepting writes if RDB snapshots are enabled (at least one save point) and the latest background save failed. This will make the user aware (in a hard way) that data is not persisting on disk properly, otherwise,strong text chances are that no one will notice and some disaster will happen.»

What u should be doing is :

# redis-cli
127.0.0.1:6379> CONFIG SET dir /data/tmp
OK
127.0.0.1:6379> CONFIG SET dbfilename temp.rdb
OK
127.0.0.1:6379> BGSAVE
Background saving started
127.0.0.1:6379>

Please Make sure /data/tmp has enough disk space.

jas

10.6k2 gold badges32 silver badges41 bronze badges

answered Mar 4, 2021 at 10:33

Vinayak S.Vinayak S.

2342 silver badges7 bronze badges

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

answered Feb 15, 2019 at 13:57

im_bhatmanim_bhatman

8161 gold badge18 silver badges26 bronze badges

for me

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

and I reload my mac, it works

answered Aug 15, 2019 at 2:33

wuhaiweiwuhaiwei

911 silver badge2 bronze badges

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

answered Sep 19, 2016 at 4:26

Soup CupSoup Cup

1011 silver badge5 bronze badges

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

answered Jun 30, 2019 at 8:52

mirekphdmirekphd

3,7602 gold badges31 silver badges48 bronze badges

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

Dharman♦

29.3k21 gold badges80 silver badges131 bronze badges

answered Nov 27, 2020 at 12:14

Binh HoBinh Ho

3,1251 gold badge25 silver badges30 bronze badges

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:

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

Finding which process was killed by Linux OOM killer

answered Jun 19, 2017 at 3:54

carton.swingcarton.swing

1,37714 silver badges12 bronze badges

Yep, this happing because current use does not have the permission to modify the «dump.rdb».

So, instead of creating a new RDB file, You can also give permission to old file(change the ownership of it).

In redis-cli enter:

config get dir

you will get «/usr/local/var/db/redis» (this is the location where redis writes the data)

go to this location using terminal

cd 
cd /usr/local/var/db

Type this command(with our username):

sudo chown -R [username] db

This will change to owner.

This works for me.

answered Jun 11, 2021 at 5:58

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.

Checked CHMOD on dir folder… found somehow the symbolic notation was different. CHMOD dir folder to 755
dbfilename permissions were good, no changes needed
Restarted redis-server
(Should’ve done this first, but ah well) Referenced the redis-server.log and found that the error was the result of access being denied.

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.

answered Jun 21, 2020 at 6:14

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

answered Jun 11, 2018 at 9:03

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)

answered May 2, 2020 at 5:21

markroxormarkroxor

5,6582 gold badges33 silver badges43 bronze badges

In my Case the Ubuntu Virtual Machine’s Disk space got Full and that’s why I was getting this Error. After deleting some files from the Disk has Solved the Issue.

answered May 29, 2021 at 17:51

Amar KumarAmar Kumar

2,2342 gold badges23 silver badges33 bronze badges

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

answered Jun 23, 2019 at 2:05

Nic WanavitNic Wanavit

2,0335 gold badges17 silver badges29 bronze badges

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.

answered Apr 17, 2020 at 22:24

ErfunErfun

1,0492 gold badges11 silver badges25 bronze badges

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

answered Oct 28, 2017 at 12:44

duhaimeduhaime

24.6k15 gold badges163 silver badges209 bronze badges

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.

answered Jan 22, 2020 at 7:31

meow2xmeow2x

2,00624 silver badges27 bronze badges

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.

answered Aug 6, 2019 at 6:40

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.

Aurelio

24.1k9 gold badges58 silver badges63 bronze badges

answered Jun 19, 2018 at 8:54

PascalculatorPascalculator

8701 gold badge10 silver badges17 bronze badges

Источник

Restart your redis server.

macOS (brew): brew services restart redis.
Linux: sudo service redis restart / sudo systemctl restart redis
Windows: Windows + R -> Type services.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.

answered Dec 18, 2019 at 12:27

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.

answered Jan 31, 2014 at 15:54

思考zhe思考zhe

5,1972 gold badges12 silver badges9 bronze badges

Using redis-cli, you can do something like this:

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

answered Oct 30, 2013 at 3:41

Axel AdventoAxel Advento

2,9753 gold badges24 silver badges32 bronze badges

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

answered Dec 13, 2013 at 22:37

ChrisChris

1,5121 gold badge12 silver badges19 bronze badges

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

answered Apr 15, 2018 at 6:42

BhindiBhindi

1,33311 silver badges16 bronze badges

In my case, it was just the privileges that I needed to allow for Redis to accept the incoming request.

answered May 16, 2022 at 10:23

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

answered Jul 13, 2014 at 18:26

smilee89smilee89

5035 silver badges9 bronze badges

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.

answered Nov 11, 2019 at 5:30

FushFush

2,41920 silver badges19 bronze badges

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.

answered Oct 25, 2013 at 4:45

Salvador DaliSalvador Dali

209k145 gold badges690 silver badges749 bronze badges

Start Redis Server in a directory where Redis has write permissions

The answers above will definitely solve your problem, but here’s what’s actually going on:

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.

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

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.

answered Sep 23, 2017 at 19:57

Govind RaiGovind Rai

13.6k9 gold badges68 silver badges81 bronze badges

Login to redis client
Execute config set stop-writes-on-bgsave-error no
Execute FLUSHALL (Data stored was not needed)
Execute config set stop-writes-on-bgsave-error yes

The process redis-rdb-bgsave was no longer running after the above steps.

answered Sep 4, 2018 at 7:09

RCKRCK

3112 silver badges4 bronze badges

$ redis-cli

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

According to Redis documentation, this is recommended only if you don’t have RDB snapshots enabled or if you don’t care about data persistence in the snapshots.

What u should be doing is :

# redis-cli
127.0.0.1:6379> CONFIG SET dir /data/tmp
OK
127.0.0.1:6379> CONFIG SET dbfilename temp.rdb
OK
127.0.0.1:6379> BGSAVE
Background saving started
127.0.0.1:6379>

Please Make sure /data/tmp has enough disk space.

jas

10.6k2 gold badges32 silver badges41 bronze badges

answered Mar 4, 2021 at 10:33

Vinayak S.Vinayak S.

2342 silver badges7 bronze badges

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

FYI: You may need to install htop to make this work : sudo apt-get install htop

—UPDATE—

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

answered Feb 15, 2019 at 13:57

im_bhatmanim_bhatman

8161 gold badge18 silver badges26 bronze badges

for me

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

and I reload my mac, it works

answered Aug 15, 2019 at 2:33

wuhaiweiwuhaiwei

911 silver badge2 bronze badges

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

answered Sep 19, 2016 at 4:26

Soup CupSoup Cup

1011 silver badge5 bronze badges

Nowadays the Redis write-access problems that give this error message to the client re-emerged in the official redis docker containers.

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

answered Jun 30, 2019 at 8:52

mirekphdmirekphd

3,7602 gold badges31 silver badges48 bronze badges

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

Dharman♦

29.3k21 gold badges80 silver badges131 bronze badges

answered Nov 27, 2020 at 12:14

Binh HoBinh Ho

3,1251 gold badge25 silver badges30 bronze badges

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:

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

Finding which process was killed by Linux OOM killer

answered Jun 19, 2017 at 3:54

carton.swingcarton.swing

1,37714 silver badges12 bronze badges

Yep, this happing because current use does not have the permission to modify the «dump.rdb».

So, instead of creating a new RDB file, You can also give permission to old file(change the ownership of it).

In redis-cli enter:

config get dir

you will get «/usr/local/var/db/redis» (this is the location where redis writes the data)

go to this location using terminal

cd 
cd /usr/local/var/db

Type this command(with our username):

sudo chown -R [username] db

This will change to owner.

This works for me.

answered Jun 11, 2021 at 5:58

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.

Checked CHMOD on dir folder… found somehow the symbolic notation was different. CHMOD dir folder to 755
dbfilename permissions were good, no changes needed
Restarted redis-server
(Should’ve done this first, but ah well) Referenced the redis-server.log and found that the error was the result of access being denied.

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.

answered Jun 21, 2020 at 6:14

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.

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

answered Jun 11, 2018 at 9:03

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

answered May 2, 2020 at 5:21

markroxormarkroxor

5,6582 gold badges33 silver badges43 bronze badges

In my Case the Ubuntu Virtual Machine’s Disk space got Full and that’s why I was getting this Error. After deleting some files from the Disk has Solved the Issue.

answered May 29, 2021 at 17:51

Amar KumarAmar Kumar

2,2342 gold badges23 silver badges33 bronze badges

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

answered Jun 23, 2019 at 2:05

Nic WanavitNic Wanavit

2,0335 gold badges17 silver badges29 bronze badges

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.

answered Apr 17, 2020 at 22:24

ErfunErfun

1,0492 gold badges11 silver badges25 bronze badges

kinit USERNAME_HERE -l 30d && aklog

answered Oct 28, 2017 at 12:44

duhaimeduhaime

24.6k15 gold badges163 silver badges209 bronze badges

answered Jan 22, 2020 at 7:31

meow2xmeow2x

2,00624 silver badges27 bronze badges

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.

answered Aug 6, 2019 at 6:40

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.

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.

Aurelio

24.1k9 gold badges58 silver badges63 bronze badges

answered Jun 19, 2018 at 8:54

PascalculatorPascalculator

8701 gold badge10 silver badges17 bronze badges

Источник

Here is the detail from the log:

=== REDIS BUG REPORT START: Cut & paste starting from here === [0/428]
[9701] 18 Jul 02:21:30.542 # Redis 2.9.7 crashed by signal: 11
[9701] 18 Jul 02:21:30.542 # Failed assertion: (:0)
[9701] 18 Jul 02:21:30.542 # — STACK TRACE
/usr/local/bin/redis-server(logStackTrace+0x52)[0x4390d2]
/usr/local/bin/redis-server(dictNext+0x68)[0x4128d8]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7fcdf3a84cb0]
/usr/local/bin/redis-server(dictNext+0x68)[0x4128d8]
/usr/local/bin/redis-server(rdbSave+0x228)[0x4255a8]
/usr/local/bin/redis-server(rdbSaveBackground+0x6f)[0x4257af]
/usr/local/bin/redis-server(serverCron+0x467)[0x414f77]
/usr/local/bin/redis-server(aeProcessEvents+0x1f3)[0x410dd3]
/usr/local/bin/redis-server(aeMain+0x2b)[0x410fbb]
/usr/local/bin/redis-server(main+0x2c4)[0x40fe34]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7fcdf36d976d]
/usr/local/bin/redis-server[0x40ff9d]
[9701] 18 Jul 02:21:30.542 # — INFO OUTPUT
[9701] 18 Jul 02:21:30.542 # # Server
redis_version:2.9.7
redis_git_sha1:a2db8e48
redis_git_dirty:1
os:Linux 3.2.0-23-generic x86_64
arch_bits:64
multiplexing_api:epoll
gcc_version:4.6.3
process_id:9701
run_id:5f48a144472ae281c1de68f5b18c8574caf48e49
tcp_port:6379
uptime_in_seconds:231
uptime_in_days:0
lru_clock:37199

Clients

connected_clients:1
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:0

Memory

used_memory:4908282496
used_memory_human:4.57G
used_memory_rss:5015216128
used_memory_peak:4908397808
used_memory_peak_human:4.57G
used_memory_lua:30720
mem_fragmentation_ratio:1.02
mem_allocator:jemalloc-3.0.0

Persistence

loading:0
rdb_changes_since_last_save:17534
rdb_bgsave_in_progress:0
rdb_last_save_time:1342549047
rdb_last_bgsave_status:err
rdb_last_bgsave_time_sec:13
rdb_current_bgsave_time_sec:-1
aof_enabled:0
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:-1
aof_current_rewrite_time_sec:-1

Stats

total_connections_received:4
total_commands_processed:44173
instantaneous_ops_per_sec:0
rejected_connections:0
expired_keys:0
evicted_keys:0
keyspace_hits:9198
keyspace_misses:1520
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:50434

Replication

role:master
connected_slaves:0

CPU

used_cpu_sys:0.59
used_cpu_user:11.56
used_cpu_sys_children:0.00
used_cpu_user_children:0.00

Commandstats

cmdstat_sadd:calls=6410,usec=14064,usec_per_call=2.19
cmdstat_zadd:calls=3957,usec=19042,usec_per_call=4.81
cmdstat_zscore:calls=364,usec=1363,usec_per_call=3.74
cmdstat_hset:calls=2410,usec=4998,usec_per_call=2.07
cmdstat_hget:calls=4355,usec=5004,usec_per_call=1.15
cmdstat_hmset:calls=6369,usec=50431,usec_per_call=7.92
cmdstat_hmget:calls=5999,usec=10266,usec_per_call=1.71
cmdstat_select:calls=5,usec=5,usec_per_call=1.00
cmdstat_keys:calls=1,usec=1219,usec_per_call=1219.00
cmdstat_multi:calls=4766,usec=1480,usec_per_call=0.31
cmdstat_exec:calls=4766,usec=16059,usec_per_call=3.37
cmdstat_info:calls=5,usec=504,usec_per_call=100.80
cmdstat_watch:calls=4766,usec=4115,usec_per_call=0.86

Cluster

cluster_enabled:0

Keyspace

db0:keys=7595100,expires=0
db1:keys=3412,expires=0
hash_init_value: 1342206335

[9701] 18 Jul 02:21:30.542 # — CLIENT LIST OUTPUT
[9701] 18 Jul 02:21:30.542 # addr=127.0.0.1:35864 fd=6 age=231 idle=40 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=info

[9701] 18 Jul 02:21:30.542 # — REGISTERS
[9701] 18 Jul 02:21:30.542 #
RAX:00007bcdd25eef40 RBX:00007fcdf2c5a080
RCX:ff4febb51ed00b65 RDX:000000000000002e
RDI:00007fccc6c09340 RSI:00007fcdbdf25600
RBP:0000000000000000 RSP:00007fff24cc7028
R8 :0000000001f34ce0 R9 :1ed00b74615f6574
R10:73616c09064febb5 R11:00007fcdbdf255f5
R12:0000000000000000 R13:00007fccc6c09340
R14:00007fcdbdf79db0 R15:00000138962c3e94
RIP:00000000004128d8 EFL:0000000000010202
CSGSFS:0000000000000033
[9701] 18 Jul 02:21:30.542 # (00007fff24cc70a0) -> 3037392d706d6574
[9701] 18 Jul 02:21:30.542 # (00007fff24cc7098) -> 0000000000467775
[9701] 18 Jul 02:21:30.542 # (00007fff24cc7090) -> 0000000000000000
[9701] 18 Jul 02:21:30.542 # (00007fff24cc7088) -> 00007fcdbdf25618
[9701] 18 Jul 02:21:30.542 # (00007fff24cc7080) -> 00000001f3000010
[9701] 18 Jul 02:21:30.542 # (00007fff24cc7078) -> 00007fcdf3000198
[9701] 18 Jul 02:21:30.542 # (00007fff24cc7070) -> 0000000000000000
[9701] 18 Jul 02:21:30.542 # (00007fff24cc7068) -> 0000000001f34c00
[9701] 18 Jul 02:21:30.542 # (00007fff24cc7060) -> ccec6b508c3dbb83
[9701] 18 Jul 02:21:30.542 # (00007fff24cc7058) -> 0000000000441490
[9701] 18 Jul 02:21:30.542 # (00007fff24cc7050) -> 0000000000441370
[9701] 18 Jul 02:21:30.542 # (00007fff24cc7048) -> 0000000000441380
[9701] 18 Jul 02:21:30.542 # (00007fff24cc7040) -> 00000000004413a0
[9701] 18 Jul 02:21:30.542 # (00007fff24cc7038) -> 00007fcdf2c10040
[9701] 18 Jul 02:21:30.542 # (00007fff24cc7030) -> 0000000001f34c00
[9701] 18 Jul 02:21:30.542 # (00007fff24cc7028) -> 00000000004255a8
[9701] 18 Jul 02:21:30.542 #
=== REDIS BUG REPORT END. Make sure to include from START to END. ===

Источник

Sometimes Redis will throw out 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.

Override Error in Redis Configuration

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.

This gives a temporary fix to the problem. However, it 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.

Save Redis on Low Memory

There might be errors during the bgsave process due to low memory.

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

Background saving is failing with a fork() error under Linux even if I’ve a lot of free RAM!

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 tells Linux to relax and perform the fork in a more optimistic allocation fashion, and this is indeed what you want for Redis.

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

Redis doesn’t need as much memory as the OS thinks it does to write to disk, so may pre-emptively fail the fork.

Источник

Содержание

RedisError: 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. #584
Comments
Clients
Memory
Persistence
Stats
Replication
Commandstats
Cluster
Keyspace
Debugging: MISCONF Redis is configured to save RDB snapshots
Override Error in Redis Configuration
Save Redis on Low Memory
Почему Redis меняет свои параметры dir и dbfilename и падает с ошибкой MISCONF Redis is configured to save RDB snapshots?
kapkaev / gist:4619127
MISCONF Redis настроен для сохранения снимков RDB
18 ответов
запустите сервер Redis в каталоге, где Redis имеет разрешения на запись

RedisError: 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. #584

Here is the detail from the log:

Clients

connected_clients:1
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:0

Memory

Persistence

Stats

Replication

used_cpu_sys:0.59
used_cpu_user:11.56
used_cpu_sys_children:0.00
used_cpu_user_children:0.00

Commandstats

Cluster

Keyspace

db0:keys=7595100,expires=0
db1:keys=3412,expires=0
hash_init_value: 1342206335

The text was updated successfully, but these errors were encountered:

Источник

Debugging: MISCONF Redis is configured to save RDB snapshots

This error occurs because of BGSAVE being failed. A lot of the times BGSAVE 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.

Sometimes Redis will throw out error:

Override Error in Redis Configuration

Using redis-cli , you can stop it trying to save the snapshot:

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.

Save Redis on Low Memory

There might be errors during the bgsave process due to low memory.

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

Background saving is failing with a fork() error under Linux even if I’ve a lot of free RAM!

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

Источник

Почему Redis меняет свои параметры dir и dbfilename и падает с ошибкой MISCONF Redis is configured to save RDB snapshots?

[80927] 24 Jan 07:04:41.643 * 1 changes in 900 seconds. Saving.
[80927] 24 Jan 07:04:41.648 * Background saving started by pid 52245
[52245] 24 Jan 07:04:41.649 # Error moving temp DB file on the final destination: Is a directory
[80927] 24 Jan 07:04:41.748 # Background saving error

Ручками забиваю пути к дампу:

но спустя какое-то время, пути сбиваются снова:

df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/vdisk 6.0G 5G 1.1G 82% /
devfs 1.0k 1.0k 0B 100% /dev

при попытке изменения политики выделения памяти в sysctl под рутом, получаю:
sysctl vm.overcommit=1
vm.overcommit: 0
sysctl: vm.overcommit=1: Operation not permitted
Ответ службы поддержки:

Здравствуйте.
На данной системе виртуализации данный параметр изменить нельзя.

Буду, конечно, переносить проекты на другой сервер. если ничего с падениями поделать нельзя. хотя этот сценарий очень нежелателен..

redis 127.0.0.1:6379> INFO
# Server
redis_version:2.6.12
redis_git_sha1:00000000
redis_git_dirty:0
redis_mode:standalone
os:FreeBSD 8.3-STABLE amd64
arch_bits:64
multiplexing_api:kqueue
gcc_version:4.2.1
process_id:80927
run_id:9f7e6b9b08f49c85f335abe0e21e8d8c4f094d71
tcp_port:6379
uptime_in_seconds:79856
uptime_in_days:0
hz:10
lru_clock:658666

# Clients
connected_clients:1
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:0

# Memory
used_memory:1164464
used_memory_human:1.11M
used_memory_rss:1164464
used_memory_peak:1244280
used_memory_peak_human:1.19M
used_memory_lua:31744
mem_fragmentation_ratio:1.00
mem_allocator:libc

# Persistence
loading:0
rdb_changes_since_last_save:0
rdb_bgsave_in_progress:0
rdb_last_save_time:1453621516
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:0
rdb_current_bgsave_time_sec:-1
aof_enabled:0
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:-1
aof_current_rewrite_time_sec:-1
aof_last_bgrewrite_status:ok

# Stats
total_connections_received:290
total_commands_processed:1077
instantaneous_ops_per_sec:0
rejected_connections:0
expired_keys:2
evicted_keys:0
keyspace_hits:722
keyspace_misses:36
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:346

# Replication
role:master
connected_slaves:0

# CPU
used_cpu_sys:106.24
used_cpu_user:5.95
used_cpu_sys_children:136.74
used_cpu_user_children:14.78

# Keyspace
db0:keys=1,expires=0
db1:keys=4,expires=3

Источник

kapkaev / gist:4619127

This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters

$ redis-cli

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

I checked the Redis logs which lead me to «Can’t save in background: fork: Cannot allocate memory». This in turn lead me to this

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.

Источник

MISCONF Redis настроен для сохранения снимков RDB

во время записи в Redis ( SET foo bar ) Я получаю следующую ошибку:

MISCONF Redis настроен для сохранения снимков RDB, но в настоящее время не удается сохранить на диске. Команды, которые могут изменять набор данных: нетрудоспособный. Пожалуйста, проверьте журналы Redis для получения подробной информации об ошибке.

в основном я понимаю, что проблема в том, что redis не может сохранять данные на диске, но не знаю, как избавиться от проблема.

и следующий вопрос имеет ту же проблему, она давно заброшена без ответов и, скорее всего, без попыток решить проблему.

18 ответов

в случае, если вы столкнулись с ошибкой, и некоторые важные данные не могут быть отброшены на работающем экземпляре redis (проблемы с разрешениями для rdb файл или его каталог неправильно, или заканчивается дисковое пространство), вы всегда можете перенаправить rdb файл для записи в другом месте.

используя redis-cli , вы можете сделать что-то вроде этого:

после этого вы можете выполнить чтобы убедиться, что данные будут записаны в the . Убедитесь, что при выполнении INFO , bgsave_in_progress уже 0 (либо операция прошла успешно, либо произошла ошибка). После этого вы можете начать резервное копирование сгенерированного rdb файл в безопасном месте.

вы можете остановить его, пытаясь сохранить снимок:

это быстрый обходной путь, но если вы заботитесь о данных, вы используете его для, Вы должны проверить, чтобы убедиться, почему bgsave не удалось в первую очередь.

могут быть ошибки во время процесса bgsave из-за нехватки памяти. Попробуйте это (из redis background save FAQ)

слишком кратко об ответе. откройте терминал и введите следующие команды

если вы работаете на машине linux, также проверьте права доступа к файлам и папкам базы данных.

БД и путь к нему можно получить через:

CONFIG получить dbfilename

и в командной строке ls -l . Разрешения для каталога должны быть 755, а те для файла должны быть 644. Также, как правило, redis-сервер выполняется как пользователь redis , поэтому его также приятно дать пользователю redis владение папкой путем выполнения sudo chown -R redis:redis /path/to/rdb/folder . Это было разработано в ответе здесь.

спасибо всем за проверку проблемы, по-видимому, ошибка была произведена во время bgsave .

для меня, введя config set stop-writes-on-bgsave-error no в оболочке и перезапуск Redis решили проблему.

запустите сервер Redis в каталоге, где Redis имеет разрешения на запись

ответы выше определенно решат вашу проблему, но вот что на самом деле происходит:

папку по умолчанию для хранения и ./ (обозначение текущего каталога). Вы можете проверить это в своем . Поэтому каталог, из которого вы запускаете сервер redis, находится там, где dump.rdb файл будет создан и обновлен.

кажется, вы запустили сервер redis в каталоге, где redis не имеет правильных разрешений для создания .

что еще хуже, redis также, вероятно, не позволит вам закрыть сервер либо до тех пор, пока он не сможет создать файл rdb для обеспечения надлежащего сохранения данных.

чтобы решить эту проблему, вы должны войти в активную клиентскую среду redis, используя redis-cli обновить dir ключ и установите его значение для вашего проекта папка или любая папка, в которой не root имеет разрешения на сохранение. Затем запустите BGSAVE , чтобы вызвать создание .

(теперь, если вы нужно сохранить дамп.файл rdb в каталоге, в котором вы запустили сервер, затем вам нужно будет изменить разрешения для каталога, чтобы redis мог писать в него. Вы можете найти stackoverflow для того, как это сделать).

теперь вы должны иметь возможность закрыть сервер redis. Обратите внимание, что мы жестко путь. Hardcoding редко является хорошей практикой, и я настоятельно рекомендую запустить сервер redis из каталога проекта и изменить dir key back to ./`.

таким образом, когда вам нужно redis для другого проекта, файл дампа будет создан в каталоге текущего проекта, а не в каталоге проекта жестко закодированного пути.

эта ошибка возникает из-за сбоя BGSAVE. Во время BGSAVE Redis разветвляет дочерний процесс для сохранения данных на диске. Хотя точную причину отказа BGSAVE можно проверить из журналов (обычно при /var/log/redis/redis-server.log на машинах с Linux), но много раз БДАЛ не потому, что вилка не может выделить память. Много раз вилка не может выделить память (хотя машина имеет достаточно оперативной памяти) из-за конфликтной оптимизации ОС.

Redis схема сохранения фона зависит от семантики копирования на запись fork в современных операционных системах: Redis forks (создает дочерний процесс), который является точной копией родительского. Дочерний процесс сбрасывает БД на диск и, наконец, завершает работу. Теоретически ребенок должен использовать столько же памяти, сколько и родитель, являющийся копией, но на самом деле благодаря семантике copy-on-write, реализованной большинством современных операционных систем, Родительский и дочерний процесс будет общие страницы памяти. Страница будет дублироваться только при изменении дочернего или родительского элемента. Поскольку теоретически все страницы могут изменяться во время сохранения дочернего процесса, Linux не может заранее сказать, сколько памяти займет ребенок, поэтому, если параметр overcommit_memory установлен в нулевую вилку, произойдет сбой, если не будет столько свободного ОЗУ, сколько требуется, чтобы действительно дублировать все родительские страницы памяти, в результате чего, если у вас есть набор данных Redis 3 ГБ и всего 2 ГБ свободной памяти, потерпеть неудачу.

установка overcommit_memory в 1 говорит Linux, чтобы расслабиться и выполнить вилку в более оптимистичном режиме распределения, и это действительно то, что вы хотите для Redis.

Redis не нужно столько памяти, сколько ОС думает, что это делает для записи на диск, поэтому может упреждающе сбой вилки.

Источник

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.

1) Solution

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.

2) Solution

Restart your redis server.

macOS (brew): brew services restart redis.
Linux: sudo service redis restart / sudo systemctl restart redis
Windows: Windows + R -> Type services.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.

3) Solution

Using redis-cli, you can do something like this:

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

4) Solution

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

5) Solution

As can be read from Redis FAQ (http://redis.io/topics/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

6) Solution

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

7) Solution

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.

Solution

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.

9) Solution

Start Redis Server in a directory where Redis has write permissions

The answers above will definitely solve your problem, but here’s what’s actually going on:

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.

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

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.

10) Solution

Login to redis client
Execute config set stop-writes-on-bgsave-error no
Execute FLUSHALL (Data stored was not needed)
Execute config set stop-writes-on-bgsave-error yes

The process redis-rdb-bgsave was no longer running after the above steps.

11) Solution

$ redis-cli

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

According to Redis documentation, this is recommended only if you don’t have RDB snapshots enabled or if you don’t care about data persistence in the snapshots.

What u should be doing is :

redis-cli

127.0.0.1:6379> CONFIG SET dir /data/tmp
OK
127.0.0.1:6379> CONFIG SET dbfilename temp.rdb
OK
127.0.0.1:6379> BGSAVE
Background saving started
127.0.0.1:6379>
Please Make sure /data/tmp has enough disk space.

12) Solution

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

FYI: You may need to install htop to make this work : sudo apt-get install htop

—UPDATE—

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

13) Solution

for me

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

and I reload my mac, it works

14) Solution

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

15) Solution

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

16) Solution

Nowadays the Redis write-access problems that give this error message to the client re-emerged in the official redis docker containers.

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

17) Solution

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:

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

Finding which process was killed by Linux OOM killer

18) Solution

Yep, this happing because current use does not have the permission to modify the «dump.rdb».

So, instead of creating a new RDB file, You can also give permission to old file(change the ownership of it).

In redis-cli enter:

config get dir

you will get «/usr/local/var/db/redis» (this is the location where redis writes the data)

go to this location using terminal

cd 
cd /usr/local/var/db

Type this command(with our username):

sudo chown -R [username] db

This will change to owner.

This works for me.

19) Solution

In my case, it was just the privileges that I needed to allow for Redis to accept the incoming request.

20) Solution

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

21) Solution

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.

Checked CHMOD on dir folder… found somehow the symbolic notation was different. CHMOD dir folder to 755
dbfilename permissions were good, no changes needed
Restarted redis-server
(Should’ve done this first, but ah well) Referenced the redis-server.log and found that the error was the result of access being denied.

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.

22) Solution

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

23) Solution

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.

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

24) Solution

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

25) Solution

26) Solution

kinit USERNAME_HERE -l 30d && aklog

27) Solution

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.

28) Solution

In my Case the Ubuntu Virtual Machine’s Disk space got Full and that’s why I was getting this Error. After deleting some files from the Disk has Solved the Issue.

29) Solution

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.

30) Solution

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.

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.

Comments Section

this is a quick workaround but you should check to make sure why bgsave failed in first place

rdb_bgsave_in_progress:0 under Persistence

For some reason when I try any config set command, it like keeps loading forever.

If you use redis mainly for caching and sessions, this is a must.

For those unfortunate ones who are on Windows, me at the moment, and whoa are using the MSOpenTech version, you have to set directory path in the following style: dir C:/Temp/. Do a bgsave to verify that it works..

Is this not dangerous? For example, NodeBB uses Redis as a data store.

That didn’t «solve the problem», it just ignored it.

How did you figure out the memory overflow was the issue? I might be having the same issue.

@DarthSpeedious I don’t remember. If I had to guess I would say that maybe something in the logs were complaining about not being able to allocate memory. Sorry I can’t be more helpful.

In first place I thought also it will be great solution to work with swap and redis combined then I did some research and reached to this article antirez.com/news/52 (http://antirez.com/news/52) , which claims it is wrong way of using redis, anyway I am not 100% agree with it, are you happy with the performance of using redis with swap?

@LoveToCode config set stop-writes-on-bgsave-error yes

LInk: redis.io/topics/faq (http://redis.io/topics/faq) Search for this: «Background saving is failing with a fork() error under Linux even if I’ve a lot of free RAM!»

@DarthSpeedious In your Redis log you would see «Cannot allocate memory» errors. See here on how to see the log file: stackoverflow.com/questions/16337107/… (http://stackoverflow.com/questions/16337107/how-to-access-redis-log-file)

Restarting RedisServer in Services.msc worked for me.

were you able to resolve this issue. If yes , could you please assist with the steps. Because placing the rdb file somewhere else wouldnt solve it i guess. I think im missing something here

What permissions should they be?

This error occurs due to starting the redis server in a directory where redis does not have permissions. I recommend reverting back to default settings after fixing the problem: See answer regarding a fix to this problem.

In addition to Govind Rai’s answer: stackoverflow.com/a/47880440/5649620

Make sure you grant permission of the non-root user for the directory that the dump file will be store in. In my case, I have a user redis so I do: sudo chown redis:redis /var/lib/redis

@GovindRai I’ve already grant redis permission by change both group and owner to redis, but doesn’t help!

Whenever i restart server i got the same issue again. Then i have to set it again. How can i make it permanent?

Output of systemctl status redis revealed that there is a warning that suggested exactly changing the overcommit_memory=0 setting. Altering that indeed solved the problem for me.

This solved the issue correctly and should be the accepted answer

So the tldr would be, with the default settings, if redis is using 10 gb of ram, you need to have 10gb of ram free for this child process to be able to execute?

@DanHastings — Yes. And setting overcommit_memory to 1 relaxes this requirement.

127.0.0.1:6379> CONFIG SET dir /root/tool (error) ERR Changing directory: Permission denied

@ZiaQamar, you can set the property permanently in redis.conf, which most likely be at /etc/redis/redis.conf, set «stop-writes-on-bgsave-error no»

Just wanted to add a comment here, as this ultimately helped resolve issues I was facing with redis in Docker. Our UAT and Dev Docker servers are Windows. Windows Defender will identify RDB files as potential viruses. So mounting your /data directory will temporarily resolve the parent issue; until Windows Defender quarantines the file, causing another. MAKE SURE you add the mounted data directory as an exception in Windows Defender to resolve this.

Reminds me: that Windows Defender alert may not necessarily be a false positive — a cryptominer can infect the official Redis image even when running it without root and with all capabilities dropped — it’s enough to expose its port to the net

Thanks, that’s a good point. Just curious, but how would an RDB file execute on the host, especially a Windows one? I suppose it could be executing within the container itself. But that’s not specific to this particular container.

Right, the payload would probably fail to execute on Windows, unless written entirely in Lua and thus as cross-platform as Redis itself… eval command is a devil’s invention, regardless of the language

If anyone is reading this I had the issue with Homebrew as well but nothing to do with the upgrade: I just needed to start the service with sudo: brew services stop redis; sudo brew services start redis.

This has been an enlightening experience; thanks very much. Apparently, our UAT/DEV compose files were exposing ports outside of the Docker network. I don’t know how this is possible, but those instances were receiving admin commands and, indeed. were launching a crypto miner. I’ve disabled those ports, turned off the local RDB mount, and re-instated the Windows Defender exception (though, that won’t matter with the mount off). I need to investigate HOW these commands were getting through our firewall, but I’m monitoring closely

BGSAVE won’t tell you right away if it failed or succeeded. You have to do INFO persistence repeatedly first and wait until rdb_bgsave_in_progress becomes 0. After that, check rdb_last_bgsave_status if it is ok.

IMO definitely not the solution. You are just telling Redis to not log those errors. But the errors are still there…

just as a first quick check, make sure you have space left on disk

Man, that was so obvious) Thanks

stopping and start did fixed it for me

Classic «have you tried turning it off and on again» answer that helped

@Bhindi: Thanks a lot — this worked for me perfectly !!! One quick question is does this affect any other sidekiq related process or anything important?

In my case(macOS), it works! I think Big Sur update cause it, so some brew system need to be updated once

Note: on macOS this file is located at /usr/local/etc/redis.conf and you need to run this command to restart redis: brew services restart redis

I tried brew uninstall redis and brew install redis to reinstall but to no avail, but this worked!

How do you check if/when the BGSAVE command is complete?

Very simple and helpful explanation