所有这些答案都不能解释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杀手杀死

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

kinit USERNAME_HERE -l 30d && aklog

我知道这个线程稍微老一些，但当我早些时候得到这个错误时，这里是为我工作的，因为我知道我没有接近内存限制-两个答案都在上面找到。

希望这能在将来帮助到需要的人。

检查CHMOD目录…发现符号符号不一样。CHMOD目录文件夹到755 Dbfilename权限很好，不需要更改 重启redis-server 参考redis-server.log，发现该错误是访问被拒绝的结果。

再次-不确定DIR文件夹的权限是如何改变的，但我假设CHMOD回到755并重新启动redis-server，因为我之后能够ping到redis服务器。

另外，需要注意的是，redis确实拥有dbfilename和DIR文件夹的所有权。

遇到此错误，并且能够从日志中找出该错误是由于磁盘空间不足造成的。所有插入到我箱子里的数据都不再需要了。所以我试着冲洗马桶。由于redis-rdb-bgsave进程正在运行，因此也不允许FLUSH数据。我按照下面的步骤，并能够继续。

登录redis客户端 执行config set stop-writes-on-bgsave-error no 执行FLUSHALL(不需要存储的数据) 执行config set stop-writes-on-bgsave-error yes

进程redis-rdb-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文件夹的所有权也是很好的。在这里的回答中已经详细说明了这一点。

在我的情况下，Ubuntu虚拟机的磁盘空间已满，这就是为什么我得到这个错误。从磁盘删除一些文件后，已解决问题。