MISCONF Redis is configured to save RDB snapshots, but it is currently not able to persist on disk.
前言配置日志
前言
完整报错如下：
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安装目录所在的挂载点，并且该挂载点是满的。我这里毫无疑问是第一个。
切换到根目录下，使用ls命令查看所有文件夹。
然后执行
du -sh *
会统计各个文件夹的大小。不过需要注意的是，如果当前目录下包含其他过大的挂载点，比如我这里的第三个挂载点有2T，可能就会等很久，或者卡死。如果遇到这种情况，使用ctrl + c强制结束进程。跳过该挂载点。
然后对后续的文件单个统计，假如我根目录下文件为：
bin
etc
boot
home
lib
那么对于boot后面的文件夹就需要挨个统计了，比如统计home的大小
du -sh home
如果出现跟最大容量很接近的文件夹，比如我的是local文件夹下面有44G 那就就进去，然后再重复上面的操作，统计该文件夹下所有文件的大小。直至找到是哪些大文件导致的磁盘空间不够。
我这里是最后找到的是tomcat的catalina.out日志文件，然后我给删除了。当然了，如果你对该服务器不熟悉的话，不认识找到的文件，还是建议问问负责这个服务器的人，看看能不能删。
删除以后重启了下tomcat服务器，就没问题了。
如果日志报错跟我的不一样，大家也可以参考以下这位的文章： Caused by: io.lettuce.core.RedisCommandExecutionException 记一次Redis报错修复 删除文件后磁盘空间未释放，参考这个： no space left on device(磁盘空间不足)----记录备忘
相关链接
您阅读本篇文章共花了：
发表评论