解决redis.exceptions.ResponseError异常:Please check the Redis logs for details about the RDB error

今天要解决的问题主要有两部分:Redis的快照持久化ERROR,还有服务器磁盘不够的异常。

一,Redis的快照持久化

项目用到的Redis主要是作为一个缓存队列,存储爬虫信息的进出,一直也没什么问题。
今天早上,检测脚本检测出的异常信息有点多,奔着解决异常的目的,手动启动了一下采集项目。这不,就出BUG了:
在这里插入图片描述
异常信息显示,Redis被配置为保存数据库快照,但它目前不能持久化到硬盘。用来修改集合数据的命令不能用。请查看Redis日志的详细错误信息。
异常的原因是: 强制关闭Redis快照导致不能持久化。
解决方案有两种:

1.命令行方式
服务器中输入redis-cli,进入redis服务。
config set stop-writes-on-bgsave-error no修改redis的配置

2.修改配置文件。

查找redis在服务器中的路径的命令:whereis redis 或者 which redis

进入redis的文件目录下:

vim 打开redis-server配置的redis.conf文件;
使用快速匹配指令:/stop-writes-on-bgsave-error;
修改stop-writes-on-bgsave-error行的yes 为no;
保存并退出。

讲道理,异常现在就没了吧?
结果又出了个新BUG。

二,服务器磁盘爆满异常

修改了redis.conf的文件,保存并退出时,出现了这个新Bug:
在这里插入图片描述
E514:write error(file system full?)
写入错误,磁盘是否满了?
使用 df -h 指令查看服务器的容器状况。
在这里插入图片描述
可以看到Avail可用磁盘量为0。

接下来,我们需要找到导致磁盘爆满的原因。
cd / 退回到根目录;
使用 du -h --max-depth=1 指令获取根目录下占磁盘最大的文件夹:
在这里插入图片描述
通过查看可以发现,/home文件占的磁盘达到了21G,是最大的。
进入home文件中,继续执行 du -h --max-depth=1,找出占磁盘最大的文件夹,进入,继续执行查看指令。
最终,我们发现占磁盘比较大的一个文件是wwroot下的一个log文件,记录的是2018年11月到2020年10月,我们一个项目运行的日志文件。磁盘占用量达到了11G。
根据项目需要和实际情况,对这些log文件执行保留或者删除操作。我们选择留下最近三个月的log文件,其他的清理掉,节省出来磁盘给其他项目。

清理文件夹

需要清理掉的文件夹,名称都是时间,例如201811,201902。能不能批量处理掉不需要的文件?

方法一
find . -type f -name *.log -mtime +300 -exec rm -fv { } ;
命令作用:在当前目录下查找x天前的后缀为log的文件并且删除。

例:
find . -type f -name *.log -mtime +300 -exec rm -fv { } ;
查找300天前的后缀名为log的文件并且删除。

命令解释:
-type f 查找的是普通文件,而不是文件夹
-name *.log 查找后缀为log的文件
-mtime +x 查找x天以前的文件,所以需要把这个x换成你自己需要查找的天数,比如30.你要删除20090808以前的,就需要计算一下,它距离现在多少天。
-exec rm -fv { } ; 把查找的文件强制删除
如果权限不足,请以root身份运行命令。
注意命令书写的格式。

方法二
rm -rf 文件名
直接删除文件夹。
在这里插入图片描述

第一种方法使用不出来效果,报提示异常:
在这里插入图片描述
有使用成功的小伙伴举个手,大家交流一下。

总结

清理完log文件以后的磁盘就很清爽了,多了10G的可用量。
再重新修改redis.conf的文件配置。
保存并退出成功后,运行项目。
项目流程和采集结果都是正常的。
问过了负责项目的小伙伴,对于这个log文件也是一点印象都没有,看信息也是一些系统记录之类的,大概率是项目自带的一些日志记录流程。
随着时间的流逝,这些遗留的log文件会占用不必要的内存或者磁盘,影响当前项目的使用。后续的异常,查找起来就不太方便了。
对于这些遗留的不受把控的文件,应该关注一下,计划实现一个能够定时清理,只保存指定日期内log的脚本。
成熟的项目应该拥有成熟的流程,自处理问题,减少后期管理的精力。