在写入Redis (SET foo bar)期间,我得到以下错误:
MISCONF Redis被配置为保存RDB快照,但当前为 无法在磁盘上持久保存。可能修改数据集的命令是 禁用。有关错误的详细信息,请查看Redis日志。
基本上我理解的问题是,redis是不能在磁盘上保存数据,但不知道如何摆脱这个问题。
下面的问题也有同样的问题,它在很久以前就被抛弃了,没有答案,很可能没有尝试解决这个问题。
在写入Redis (SET foo bar)期间,我得到以下错误:
MISCONF Redis被配置为保存RDB快照,但当前为 无法在磁盘上持久保存。可能修改数据集的命令是 禁用。有关错误的详细信息,请查看Redis日志。
基本上我理解的问题是,redis是不能在磁盘上保存数据,但不知道如何摆脱这个问题。
下面的问题也有同样的问题,它在很久以前就被抛弃了,没有答案,很可能没有尝试解决这个问题。
当前回答
在我的情况下,这只是特权,我需要允许Redis接受传入的请求。
所以我重启了Redis服务通过Homebrew brew服务停止Redis和brew服务启动Redis和运行Redis服务器本地Redis -server。命令提示符要求我允许传入请求,然后它开始工作。
其他回答
如果你遇到错误,一些重要的数据不能被丢弃在运行的redis实例上(rdb文件或其目录的权限不正确,或运行出磁盘空间),你总是可以重定向rdb文件写入其他地方。
使用redis-cli,你可以这样做:
CONFIG SET dir /tmp/some/directory/other/than/var
CONFIG SET dbfilename temp.rdb
在此之后,您可能想要执行BGSAVE命令,以确保数据将被写入rdb文件。确保当你执行INFO持久化时,bgsave_in_progress已经是0,rdb_last_bgsave_status是ok。在此之后,您现在可以开始在安全的地方备份生成的rdb文件。
由于内存不足,bgsave过程中可能会出现错误。试试这个(从redis后台保存FAQ)
echo 'vm.overcommit_memory = 1' >> /etc/sysctl.conf
sysctl vm.overcommit_memory=1
在采取任何行动之前检查你的Redis日志。这个线程中的一些解决方案可能会删除你的Redis数据,所以要小心你在做什么。
在我的例子中,机器的内存快用完了。当主机上没有更多的空闲磁盘空间时,也会发生这种情况。
现在,Redis的写访问问题在官方的Redis docker容器中重新出现,给客户端这个错误消息。
来自官方Redis映像的Redis试图将.rdb文件写入containers /data文件夹中,这是相当不幸的,因为它是一个根目录拥有的文件夹,而且它也是一个非持久化的位置(如果容器/pod崩溃,写入那里的数据将消失)。
所以在一个小时的不活动后,如果你以非根用户运行你的redis容器(例如docker run -u 1007而不是默认的docker run -u 0),你会在你的服务器日志中得到一个非常详细的错误信息(参见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
所以你需要做的是将容器的/data文件夹映射到一个外部位置(非根用户,这里:1007,有写权限,比如主机上的/tmp),例如:
docker run --rm -d --name redis -p 6379:6379 -u 1007 -v /tmp:/data redis
所以这是官方docker镜像的错误配置(应该写入/tmp而不是/data),产生了这个“定时炸弹”,你很可能只会在生产中遇到…在某个特别安静的假日周末过夜:/
在我的例子中,原因是磁盘的可用空间非常低(只有35 Mb)。我做了以下的事情
停止所有Redis相关进程 删除磁盘中的一些文件,以腾出足够的空间 删除redis转储文件(如果不需要现有数据) Sudo rm /var/lib/redis/* 删除所有现有数据库的所有键 Sudo redis-cli flushall 重新启动所有芹菜任务,并检查相应的日志是否有任何问题