【服务器运维】硬盘满了,Redis读写失败 MISCONF Redis is configured to save RDB snapshots, but is currently not able

简介: 【服务器运维】硬盘满了,Redis读写失败 MISCONF Redis is configured to save RDB snapshots, but is currently not able



今天早上发现公司项目进不去了,报 502 错误,于是直接访问后端,发现后端崩了,提示 MISCONF Redis is configured to save RDB snapshots 错误,完整的错误如下。

2022-09-08 05:26:16.039 ERROR 5380 --- [redisson-timer-4-1] o.r.c.handler.PingConnectionHandler      : Unable to send PING command over channel: [id: 0x05f63864, L:/127.0.0.1:56261 - R:127.0.0.1/127.0.0.1:6379]
org.redisson.client.RedisException: MISCONF Redis is configured to save RDB snapshots, but is currently not able to persist on disk. Commands that may modify the data set are disabled. Please check Redis logs for details about the error.. channel: [id: 0x05f63864, L:/127.0.0.1:56261 - R:127.0.0.1/127.0.0.1:6379] command: (PING), promise: java.util.concurrent.CompletableFuture@22817c3c[Not completed, 1 dependents], params: []
  at org.redisson.client.handler.CommandDecoder.decode(CommandDecoder.java:370) ~[redisson-3.17.5.jar:3.17.5]
  at org.redisson.client.handler.CommandDecoder.decodeCommand(CommandDecoder.java:198) ~[redisson-3.17.5.jar:3.17.5]
  at org.redisson.client.handler.CommandDecoder.decode(CommandDecoder.java:137) ~[redisson-3.17.5.jar:3.17.5]
  at org.redisson.client.handler.CommandDecoder.decode(CommandDecoder.java:113) ~[redisson-3.17.5.jar:3.17.5]
  at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:510) ~[netty-codec-4.1.79.Final.jar:4.1.79.Final]
  at io.netty.handler.codec.ReplayingDecoder.callDecode(ReplayingDecoder.java:366) ~[netty-codec-4.1.79.Final.jar:4.1.79.Final]
  at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:279) ~[netty-codec-4.1.79.Final.jar:4.1.79.Final]
  at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[netty-transport-4.1.79.Final.jar:4.1.79.Final]
  at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[netty-transport-4.1.79.Final.jar:4.1.79.Final]
  at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) ~[netty-transport-4.1.79.Final.jar:4.1.79.Final]
  at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410) ~[netty-transport-4.1.79.Final.jar:4.1.79.Final]
  at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[netty-transport-4.1.79.Final.jar:4.1.79.Final]
  at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[netty-transport-4.1.79.Final.jar:4.1.79.Final]
  at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919) ~[netty-transport-4.1.79.Final.jar:4.1.79.Final]
  at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166) ~[netty-transport-4.1.79.Final.jar:4.1.79.Final]
  at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:722) ~[netty-transport-4.1.79.Final.jar:4.1.79.Final]
  at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:658) ~[netty-transport-4.1.79.Final.jar:4.1.79.Final]
  at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:584) ~[netty-transport-4.1.79.Final.jar:4.1.79.Final]
  at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:496) ~[netty-transport-4.1.79.Final.jar:4.1.79.Final]
  at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997) ~[netty-common-4.1.79.Final.jar:4.1.79.Final]
  at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) ~[netty-common-4.1.79.Final.jar:4.1.79.Final]
  at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) ~[netty-common-4.1.79.Final.jar:4.1.79.Final]
  at java.base/java.lang.Thread.run(Thread.java:833) ~[na:na]

于是我看了眼任务管理器,一切正常,甚至还很空。

Spring 日志里有这样的错误大概 100 多份,简单翻译了下才发现,是硬盘满了,于是…


接着赶紧到项目文件夹查看,是什么文件这么占内存


原来是企业微信的会话存档,塞满了整个服务器硬盘,甚至还不够用。

原因是营销部门的同事在经销商群里发大文件,然后我的 OA 项目把这些文件都拉了下来

于是我将大于 2GB 的文件进行删除,保证服务器硬盘有足够的存储空间,接着重启服务器

重启后,把各个前后端项目逐个启动,最后一切正常!

幸好发现得早,要是上班了才发现,就会对公司员工造成影响了…

所以起个早还是挺好的…


相关文章
|
存储 缓存 NoSQL
Redis 服务器全方位介绍:从入门到核心原理
Redis是一款高性能内存键值数据库,支持字符串、哈希、列表等多种数据结构,广泛用于缓存、会话存储、排行榜及消息队列。其单线程事件循环架构保障高并发与低延迟,结合RDB和AOF持久化机制兼顾性能与数据安全。通过主从复制、哨兵及集群模式实现高可用与横向扩展,适用于现代应用的多样化场景。合理配置与优化可显著提升系统性能与稳定性。
400 0
|
5月前
|
运维 前端开发 JavaScript
半夜服务器告警不再错过!运维人员必备的语音通知方案
为解决深夜服务器宕机错过告警的问题,本文介绍一款专为个人开发者与运维人员设计的语音通知方案。通过电话直接推送重要告警,确保第一时间响应,避免故障扩大。支持多种编程语言调用,配置简单,3步即可完成,实时性强,适合各类关键业务场景。
484 5
|
4月前
|
运维 监控 安全
“没服务器了,那我这运维是白干了吗?”——无服务器架构对运维的冲击与转机
“没服务器了,那我这运维是白干了吗?”——无服务器架构对运维的冲击与转机
129 0
|
5月前
|
运维 Prometheus 监控
“服务器又宕了?”别急,智能运维教你如何未卜先知!
“服务器又宕了?”别急,智能运维教你如何未卜先知!
161 0
|
9月前
|
NoSQL Redis Docker
Docker——阿里云服务器利用docker搭建redis集群
本文详细记录了使用Docker搭建Redis集群的过程,包括检查Docker和Docker Compose的安装、创建Redis配置文件、编写`docker-compose.yml`文件、启动Redis节点、创建Redis集群的具体步骤,以及最终的验证方法。文章还提供了在多服务器环境下搭建Redis集群的注意事项,帮助读者全面了解 Redis 集群的部署流程。
1091 68
|
10月前
|
存储 NoSQL 安全
Redis的两种持久化方式---RDB、AOF
通过本文的介绍,我们详细讲解了Redis的两种主要持久化方式:RDB和AOF。每种方式都有其独特的优缺点和适用场景。在实际应用中,可以根据具体需求选择合适的持久化方式,或者同时启用RDB和AOF,以达到最佳效果。希望本文能帮助您更好地理解和应用Redis的持久化机制,构建高效、可靠的数据存储解决方案。
993 79
|
9月前
|
弹性计算 人工智能 运维
摆脱繁琐命令-让运维更加流畅-阿里云ECS操作系统控制台运维篇
阿里云操作系统控制台提供了便捷的服务器监控与管理功能,简化了运维工作。通过将多台服务器纳入统一监控平台,用户可以快速查看CPU、内存、磁盘和网络等关键资源的使用情况,避免了逐一远程连接查询的繁琐操作。此外,该工具支持自动化数据汇总,极大地方便了日报、周报和月报的编写。测试过程中,系统展示了良好的稳定性和响应速度,尤其在网络抖动和大文件健康状态测试中表现出色。整体体验流畅,显著提升了运维效率。 操作系统控制台地址:[点击访问](https://alinux.console.aliyun.com/)
335 26
摆脱繁琐命令-让运维更加流畅-阿里云ECS操作系统控制台运维篇
|
9月前
|
机器学习/深度学习 人工智能 运维
机器学习+自动化运维:让服务器自己修Bug,运维变轻松!
机器学习+自动化运维:让服务器自己修Bug,运维变轻松!
400 14
|
9月前
|
运维 安全 开发工具
GitHub 热门开源运维工具 Websoft9:如何实现服务器管理效率翻倍?
Websoft9 提供 200+ 开源应用一键部署,支持容器化隔离、GitOps 自动化和企业级安全防护,助力服务器管理效率提升 80%。
316 1
|
9月前
|
机器学习/深度学习 人工智能 运维
基于AI的自动化服务器管理:解锁运维的未来
基于AI的自动化服务器管理:解锁运维的未来
861 0

热门文章

最新文章