在写入Redis (SET foo bar)期间,我得到以下错误:

MISCONF Redis被配置为保存RDB快照,但当前为 无法在磁盘上持久保存。可能修改数据集的命令是 禁用。有关错误的详细信息,请查看Redis日志。

基本上我理解的问题是,redis是不能在磁盘上保存数据,但不知道如何摆脱这个问题。

下面的问题也有同样的问题,它在很久以前就被抛弃了,没有答案,很可能没有尝试解决这个问题。


当前回答

在Redis有写权限的目录下启动Redis服务器

上面的答案肯定能解决你的问题,但实际情况是这样的:

存储rdb的默认位置。转储文件为。/(表示当前目录)。您可以在redis.conf文件中验证这一点。因此,启动redis服务器的目录就是转储文件所在的目录。RDB文件将被创建和更新。

似乎您已经开始运行redis服务器在一个目录,其中redis没有正确的权限来创建转储。rdb文件。

更糟糕的是,redis可能也不允许你关闭服务器,直到它能够创建rdb文件,以确保正确保存数据。

要解决这个问题,你必须使用redis-cli进入活动的redis客户端环境,更新dir键,并将其值设置为你的项目文件夹或任何非root用户有权限保存的文件夹。然后运行BGSAVE调用转储的创建。rdb文件。

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

(现在,如果您需要保存转储。RDB文件在您启动服务器的目录中,然后您需要更改该目录的权限,以便redis可以写入它。您可以搜索stackoverflow如何做到这一点)。

你现在应该可以关闭redis服务器了。注意,我们对路径进行了硬编码。硬编码很少是一个好的实践,我强烈建议从你的项目目录启动redis服务器,并将dir键更改回。/ '。

CONFIG SET dir "./"
BGSAVE

这样,当您需要redis为另一个项目时,转储文件将创建在当前项目的目录中,而不是在硬编码路径的项目目录中。

其他回答

# 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

此错误是由于BGSAVE失败导致的。在BGSAVE期间,Redis会fork一个子进程来将数据保存到磁盘上。虽然BGSAVE失败的确切原因可以从日志中检查(通常在linux机器上的/var/log/redis/redis-server.log),但很多时候bgive失败是因为fork不能分配内存。很多时候,由于操作系统的优化冲突,fork无法分配内存(尽管机器有足够的可用RAM)。

可以从Redis常见问题中阅读:

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不需要像操作系统认为的那样多的内存来写入磁盘,所以可能会预先导致fork失败。

要解决这个问题,您可以:

修改/etc/sysctl.conf,增加:

vm.overcommit_memory=1

然后重新启动sysctl:

在FreeBSD上:

sudo /etc/rc.d/sysctl reload

在Linux上:

sudo sysctl -p /etc/sysctl.conf

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

遇到此错误,并且能够从日志中找出该错误是由于磁盘空间不足造成的。所有插入到我箱子里的数据都不再需要了。所以我试着冲洗马桶。由于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在执行以上步骤后不再运行。

我也遇到过类似的问题,这背后的主要原因是redis的内存消耗。 我的EC2机器有8GB内存(大约7.4 gb可用)

当我的程序运行时,RAM使用率上升到7.2 GB,只剩下大约100MB的RAM,这通常会触发MISCONF Redis错误…

可以使用htop命令确定内存消耗。执行htop命令后,查找Mem属性。如果它显示出较高的消耗(比如我的情况是7.2GB/7.4GB),那么最好将实例升级为更大的内存。 在这种情况下,使用set stop-writes-on-bgsave-error no对服务器来说将是一场灾难,并可能导致中断服务器上运行的其他服务(如果有的话)。所以,最好避免配置命令和升级你的REDIS机器。

供您参考:您可能需要安装htop才能使其工作:sudo apt-get install htop

另一种解决方案是在你的系统上运行一些其他的内存大的服务,检查在你的服务器/机器/实例上运行的其他服务,如果没有必要就停止它。要检查机器上运行的所有服务,请使用service——status-all

对于那些直接粘贴config命令的人,建议在使用这些命令之前,请做一些研究,至少警告用户。正如@Rodrigo在评论中提到的:“忽视错误看起来并不酷。”

——更新

你也可以配置maxmemory和maxmemory-policy来定义当达到特定的内存限制时Redis的行为。 例如,如果我想保持6GB的内存限制,并从DB中删除最近最少使用的键,以确保redis mem的使用不超过6GB,那么我们可以设置以下两个参数(在redis.conf或CONFIG set命令中):

maxmemory 6gb
maxmemory-policy allkeys-lru

你可以为这两个参数设置很多其他的值,你可以从这里阅读:https://redis.io/topics/lru-cache