所有这些答案都不能解释RDB保存失败的原因。

作为我的情况，我检查了redis日志，发现:

14975:M 18 Jun 13:23:07.354 #后台保存被信号9终止

在终端执行如下命令:

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

它显示:

/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

就是这样!这个进程(redis保存rdb)被OOM杀手杀死

是指:

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

查找哪个进程被Linux OOM杀手杀死

我也面临着同样的问题。两个答案(被点赞最多的和被接受的)都只是暂时的解决办法。

此外，配置set stop-writes-on-bgsave-error no是一种可怕的忽略这个错误的方式，因为这个选项所做的是阻止redis通知写已经停止，并继续在快照中不写数据。这是简单地忽略这个错误。 请参考这个

至于在redis-cli的config中设置dir，当你重新启动redis服务时，这个问题也会被清除，并且会再次弹出相同的错误。在redis.conf中dir的默认值是。/，如果你以root用户启动redis，那么。/是/，写权限不被授予，因此会出现错误。

最好的方法是在redis.conf文件中设置dir参数，并对该目录设置适当的权限。大多数debian发行版都将它放在/etc/redis/redis.conf中

使用redis-cli，你可以阻止它尝试保存快照:

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

这是一个快速的解决方法，但是如果你关心使用它的数据，你应该检查一下为什么bgsave首先失败了。

如果您在Linux机器上工作，还要重新检查数据库的文件和文件夹权限。

数据库和它的路径可以通过以下方式获得:

在redis-cli:

CONFIG GET dir 配置dbfilename

在命令行中ls -l。目录的权限应为755，文件的权限应为644。此外，通常redis-server作为用户redis执行，因此通过执行sudo chown -R redis:redis /path/to/rdb/folder，给用户redis文件夹的所有权也是很好的。在这里的回答中已经详细说明了这一点。

我在使用AFS磁盘空间的服务器上工作时遇到了这个问题，因为我的身份验证令牌已经过期，当redis-server试图保存时产生了Permission Denied响应。我通过刷新我的令牌来解决这个问题:

kinit USERNAME_HERE -l 30d && aklog

$ redis-cli

设置stop-writes-on-bgsave-error no

根据Redis文档，只有当您没有启用RDB快照或您不关心快照中的数据持久性时，才建议这样做。

默认情况下，如果RDB快照启用(至少一个保存点)并且最近的后台保存失败，Redis将停止接受写入。这将使用户意识到(以一种艰难的方式)数据没有正确地保存在磁盘上，否则，强文本的机会是没有人会注意到，并且会发生一些灾难。”

你应该做的是:

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

请确保/data/tmp有足够的磁盘空间。