前言
Error in execution; nested exception is
io.lettuce.core.RedisCommandExecutionException:
MISCONF Redis is configured to save RDB snapshots,
but it is currently not able to persist on disk.
Commands that may modify the data set are disabled,
because this instance is configured to report errors during
writes if RDB snapshotting fails (stop-writes-on-bgsave-error option).
Please check the Redis logs for details about the RDB error.
莫名其妙服务器上的redis
报这个错误。从字面理解来看是持久化的问题,但是导致这个错误的原因有很多,具体还是得看下日志
才行。一般的排错流程是: 读懂报错 -> 查看日志 -> 搜索相关错误 -> 定位错误 -> 解决
。 问题在于,不是我安装的redis
,而这个框架默认不记录日志,不幸的是,安装的人没给配置日志。。。。
配置日志
既然没有的话,那就先配置一下吧。首先查看服务器的redis是否在正常运行,输入
ps -ef | grep redis
root 8642 5461 0 09:16 pts/0 00:00:00 grep redis
root 26157 1 0 2022 ? 02:06:06 redis-server 127.0.0.1:6379
有两个,第一个是我们ps -ef | grep redis
这条命令的进程,下面的就是redis服务
的进程了。所以服务是开启的。我们先输入以下命令关闭服务
(得确定当前没有什么项目在用
,不然要挨骂)
kill -9 26157
我这里的26157
是上面的redis-server的进程
。然后进到redis的安装目录下,找到redis.conf文件,打开搜索找到logfile
这一栏
这里我使用的XFtp
操作连接的服务器,所以可以使用记事本
操作。在双引号里面设置日志存储路径。比如
/home/workhome/zs/redis/redis.log
然后保存,并且以该配置文件启动redis服务,在redis安装目录
下,输入
redis-server redis.conf
ps -ef | grep redis
然后再去设置的目录下 查看有没有日志生成
好了现在日志配置好了。然后复现一下错误
,只要使用了redis
应该还是会报刚刚的的错误,再查看日志
就好了。
Write error saving DB on disk: No space left on device
df -h
文件系统 容量 已用 可用 已用% 挂载点
/dev/** 50G 50G 0 100% /
tmpfs 50G 40G 10G 80% /dev/sxm
/dev/** 5T 2T 3T 40% /boot
/dev/** 200M 260K 200M 1% /boot/efi
这里也简单说一下,各列的意思:
文件系统
:表明当前的文件系统位于哪里,唯一,可以看作windows的盘符
(C盘、D盘、E盘)。- 容量:最大可容纳的大小。各个
文件系统独立
。 - 已用:已使用的大小。
- 可用:剩余大小。
- 已用%:已用百分比。
- 挂载点:这个可以看作
文件系统在当前系统里的映射
。就是文件系统是不显示的,显示给用户的是挂载点
。
需要注意的是,左侧的文件系统
与右侧的挂载点
对应。比如第一个的挂载点
为/ ,也就是根目录下
,大小为50G
,但是第二个文件系统的挂载点为:/dev/sxm
,也在根目录
下,大小为60G
。你可能已经发现了,根目录总容量才50G
,那它的子目录怎么能有60G
大小呢?没错,但是文件系统让它们独立
。
简而言之就是/
目录下的大小,不包含/dev/sxm
、/boot
、/boot/efi
等挂载点文件的大小。
现在我们继续,很明显我们需要排查的是redis安装目录所在的挂载点
,并且该挂载点是满的
。我这里毫无疑问是第一个
。
du -sh *
会统计各个文件夹的大小。不过需要注意的是,如果当前目录下包含其他过大的挂载点
,比如我这里的第三个挂载点有2T
,可能就会等很久,或者卡死。如果遇到这种情况,使用ctrl + c
强制结束进程。跳过该挂载点。
bin
etc
boot
home
lib
那么对于boot后面的文件夹就需要挨个统计
了,比如统计home
的大小
du -sh home
如果出现跟最大容量很接近的文件夹,比如我的是local
文件夹下面有44G
那就就进去,然后再重复上面的操作,统计该文件夹下所有文件的大小
。直至找到是哪些大文件导致的磁盘空间不够
。
我这里是最后找到的是tomcat的catalina.out日志文件
,然后我给删除了。当然了,如果你对该服务器不熟悉的话,不认识找到的文件,还是建议问问负责这个服务器的人,看看能不能删
。
如果日志报错跟我的不一样,大家也可以参考以下这位的文章: Caused by: io.lettuce.core.RedisCommandExecutionException 记一次Redis报错修复
删除文件后磁盘空间未释放,参考这个: no space left on device(磁盘空间不足)—-记录备忘
原文地址:https://blog.csdn.net/qq_44717657/article/details/129851028
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。
如若转载,请注明出处:http://www.7code.cn/show_43633.html
如若内容造成侵权/违法违规/事实不符,请联系代码007邮箱:suwngjj01@126.com进行投诉反馈,一经查实,立即删除!