MISCONF Redis配置为保存RDB快照

f4t66c6m  于 2022-09-21  发布在  Redis
关注(0)|答案(22)|浏览(326)

在写入Redis(SET foo bar)期间,我收到以下错误:
MISCONF Redis被配置为保存RDB快照,但目前无法在磁盘上保存。可以修改数据集的命令被禁用。有关该错误的详细信息,请查看Redis日志。

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

the following question也有同样的问题,它很久以前就被放弃了,没有答案,很可能没有尝试解决问题。

bq8i3lrv

bq8i3lrv1#

在我的例子中,这只是我需要允许Redis接受传入请求所需的权限。

因此,我通过Homebrew brew services stop redisbrew services start redis重新启动了Redis服务,并在本地运行了Redis服务器redis-server。命令提示符要求我允许传入的请求,然后它开始工作。

jutyujz0

jutyujz02#

我也面临着同样的问题。这两个答案(最受欢迎的和被接受的答案)只是为同样的问题提供了一个暂时的解决方案。

此外,config set stop-writes-on-bgsave-error no是一种忽略此错误的可怕方式,因为此选项的作用是阻止redis通知写入已停止,并在不将数据写入快照的情况下继续进行。这简直是忽略了这个错误。Refer this

至于在redis-cli中设置config中的dir,一旦重启redis服务,也会被清除,并再次弹出相同的错误。redis.confdir的缺省值是./,如果您以根用户身份启动redis,则./是未授予写入权限的/,因此出现错误。

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

3zwjbxry

3zwjbxry3#

我知道这个帖子稍微老了一点,但当我早些时候收到这个错误时,我知道我远远没有达到内存限制,这是对我起作用的--两个答案都在上面找到了。

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

1.已检查目录文件夹上的CHMOD...不知何故发现符号符号是不同的。将CHMOD目录文件夹设置为755
1.数据库文件名权限良好,无需更改
1.重启redis-server
1.(应该先这样做,但很好)参考了redis-server.log,发现错误是访问被拒绝的结果。

再说一次-不确定DIR文件夹上的权限是如何更改的,但我假设chmod回到755并重新启动redis-server会处理它,因为我之后能够ping到redis服务器。

还要注意的是,redis确实拥有dbfilename和DIR文件夹的所有权。

omjgkv6w

omjgkv6w4#

FWIW,我遇到了这个,解决方案是简单地向盒子中添加一个交换文件。我使用了这个方法:https://www.digitalocean.com/community/tutorials/how-to-add-swap-on-ubuntu-14-04

7uzetpgm

7uzetpgm5#

是的,之所以会发生这种情况,是因为当前用户没有修改“ump.rdb”的权限。

因此,您还可以向旧文件授予权限(更改其所有权),而不是创建新的RDB文件。

在redis-cli中输入:

config get dir

您将看到“/usr/local/var/db/redis”(这是redis写入数据的位置)

使用终端转到此位置

cd 
cd /usr/local/var/db

键入此命令(使用我们的用户名):

sudo chown -R [username] db

这将更改为所有者。

这对我很管用。

zzwlnbp8

zzwlnbp86#

所有这些答案都不能解释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内核:[28152358.208108]已终止进程28416(redis服务器)总计-vm:7660204kB,anon-rss:2285492kB,文件rss:0kb

就是这样!此进程(redis存储rdb)被OOM killer终止

参考:

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

Finding which process was killed by Linux OOM killer

pu82cl6c

pu82cl6c7#

如今,向客户端发送此错误消息的Redis写访问问题再次出现在官方的redis坞站容器中。

the official redis image中的redis试图在Containers /data文件夹中写入.rdb文件,这是非常不幸的,因为它是一个根拥有的文件夹,也是一个非持久位置(如果您的容器/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文件夹Map到外部位置(非根用户,此处为:1007,具有写访问权限,例如主机上的/tmp),例如:

docker run --rm -d --name redis -p 6379:6379 -u 1007 -v /tmp:/data redis

因此,这是官方docker映像的错误配置(它应该写入/tmp,而不是/data),从而产生了这个您很可能只会在生产中遇到的“定时炸弹”……在一些特别安静的假日周末过夜:/

8qgya5xd

8qgya5xd8#

redis.conf~235上,让我们尝试这样更改配置

- stop-writes-on-bgsave-error yes
+ stop-writes-on-bgsave-error no
vd2z7a6w

vd2z7a6w9#

对我来说

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

我重新装上我的Mac,它就能工作了

j13ufse2

j13ufse210#

一个更持久的修复方法可能是查看/etc/redis/redis.conf第200-250行,其中有一些RDB特性的设置,这些设置在2.x版本中还不是redis的一部分。

值得注意的是

dir ./

可以更改为

dir /home/someuser/redislogfiledirectory

或者,您可以注解掉所有的保存行,而不必担心持久性。(参见/etc/redis/redis.conf中的注解)

还有,别忘了

service redis-server stop
service redis-server start
b91juud3

b91juud311#

我遇到了类似的问题,背后的主要原因是Redis消耗了内存(RAM)。我的EC2机器有8 GB内存(可供使用的内存约为7.4)

当我的程序运行时,RAM使用率上升到7.2 GB,几乎没有留下大约100MB的RAM,这通常会触发MISCONF Redis error ...

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

仅供参考:您可能需要安装HTOP才能运行:sudo apt-get install htop

另一个解决方案可以是在您的系统上运行的其他一些占用大量内存的服务,检查您的服务器/机器/示例上正在运行的其他服务,并在不必要的情况下停止它。要检查您的计算机上运行的所有服务,请使用service --status-all

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

-更新-

您还可以配置maxmemorymaxmemory-policy,以定义在达到特定内存限制时Redis的行为。例如,如果我想保留6 GB的内存限制,并从数据库中删除最近最少使用的密钥,以确保redis内存使用量不超过6 GB,那么我们可以设置这两个参数(在redis.conf或config set命令中):

maxmemory 6gb
maxmemory-policy allkeys-lru

您可以从这里阅读有关这两个参数的许多其他值:https://redis.io/topics/lru-cache

6ss1mwsb

6ss1mwsb12#

使用redis-cli,您可以停止尝试保存快照:

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

这是一个快速的变通方法,但是如果您关心您正在使用它的数据,您应该检查以确保bgsave首先失败的原因。

r9f1avp5

r9f1avp513#

$redis-cli
CONFIG SET STOP-WRITE-ON-BGSAVE-错误号

根据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有足够的磁盘空间。

suzh9iv8

suzh9iv814#

遇到了此错误,并且能够从日志中找出错误是因为磁盘空间不足。在我的箱子里插入的所有数据都不再需要了。所以我试着用闪光灯。由于redis-rdb-bgsave进程正在运行,因此也不允许刷新数据。我遵循了下面的步骤,并能够继续下去。

1.登录Redis客户端
1.执行CONFIG SET STOP-WRITES-ON-BGSAVE-ERROR NO
1.执行FLUSHALL(不需要存储数据)
1.执行CONFIG SET STOP-WRITES-ON-BGSAVE-Error YES

执行上述步骤后,进程redis-rdb-bgsave不再运行。

wkftcu5l

wkftcu5l15#

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

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

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

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

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

要解决此问题,您必须使用redis-cli进入活动的redis客户端环境并更新dir项,并将其值设置为您的项目文件夹或非超级用户有权保存的任何文件夹。然后运行BGSAVE以调用dump.rdb文件的创建。

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

(现在,如果您“需要”将dup.rdb文件保存在启动服务器的目录中,则需要更改该目录的权限,以便redis可以对其进行写入。您可以搜索StackOverflow了解如何做到这一点)。

您现在应该能够关闭redis服务器了。请注意,我们对路径进行了硬编码。硬编码很少是一种好的做法,我强烈建议从您的项目目录启动redis服务器并更改dir key back to./`。

CONFIG SET dir "./"
BGSAVE

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

相关问题