【服务器运维】硬盘满了,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 的文件进行删除,保证服务器硬盘有足够的存储空间,接着重启服务器

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

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

所以起个早还是挺好的…


相关文章
|
6月前
|
存储 运维 数据挖掘
服务器数据恢复—EqualLogic存储硬盘出现坏道的数据恢复案例
某品牌EqualLogic PS6100存储阵列上有一组由16块硬盘组建的raid5磁盘阵列。磁盘阵列上层划分多个大小不同的卷,存放虚拟机文件。 硬盘出现故障导致存储阵列不可用,需要恢复存储阵列中的数据。
|
6月前
|
存储 运维 Oracle
服务器数据恢复—存储硬盘指示灯亮黄灯,RAID5阵列崩溃的数据恢复案例
服务器存储数据恢复环境: 某单位一台某品牌DS5300存储,1个机头+4个扩展柜,50块的硬盘组建了两组RAID5阵列。一组raid5阵列有27块硬盘,存放Oracle数据库文件。存储系统上层一共划分了11个卷。 服务器存储故障: 存储设备上两个硬盘指示灯亮黄色。其中一组RAID5阵列崩溃,存储不可用,设备已经过保。
|
6月前
|
存储 运维 数据挖掘
服务器数据恢复—Raid5阵列2块硬盘损坏,热备盘未激活的数据恢复
EMC存储上有一组由多块stat硬盘组建的raid5磁盘阵列,该raid5阵列中有两块热备盘。上层采用的是zfs文件系统。 raid5阵列中2块硬盘出现故障,只有一块热备盘激活。
|
9月前
|
运维 前端开发 JavaScript
半夜服务器告警不再错过!运维人员必备的语音通知方案
为解决深夜服务器宕机错过告警的问题,本文介绍一款专为个人开发者与运维人员设计的语音通知方案。通过电话直接推送重要告警,确保第一时间响应,避免故障扩大。支持多种编程语言调用,配置简单,3步即可完成,实时性强,适合各类关键业务场景。
701 5
|
8月前
|
存储 运维 Oracle
服务器数据恢复—服务器存储硬盘指示灯亮黄灯的数据恢复案例
某单位的一台某品牌存储设备,该系统由1个机头+4个扩展柜组成,一共有50块硬盘组建了两组RAID5阵列。上层划分了11个卷。 一组RAID崩溃,该组RAID由27块硬盘组建,存放的是Oracle数据库文件。 服务器不可用,已经过保。
|
8月前
|
运维 监控 安全
“没服务器了,那我这运维是白干了吗?”——无服务器架构对运维的冲击与转机
“没服务器了,那我这运维是白干了吗?”——无服务器架构对运维的冲击与转机
177 0
|
9月前
|
运维 Prometheus 监控
“服务器又宕了?”别急,智能运维教你如何未卜先知!
“服务器又宕了?”别急,智能运维教你如何未卜先知!
210 0
|
9月前
|
Oracle 安全 数据挖掘
服务器数据恢复—RAID硬盘离线导致卷无法挂载的数据恢复案例
服务器数据恢复环境&故障: 某公司一台服务器上有一组由24块FC硬盘组建的raid。 服务器出现故障,无法正常工作。 经过初步检测,管理员发现导致服务器故障的原因是raid中有两块硬盘掉线,导致卷无法挂载。
|
10月前
服务器数据恢复—服务器raid5阵列2块硬盘掉线的数据恢复案例
某品牌型号为X3850服务器上有一组由14块数据盘和1块热备盘组建的raid5磁盘阵列。 服务器在正常使用过程中突然崩溃,管理员查看raid5阵列故障情况的时发现磁盘阵列中有2块硬盘掉线,但是热备盘没有启用。
|
11月前
|
存储 数据挖掘
服务器数据恢复—V7000存储上raid5阵列多块硬盘离线的数据恢复方案
V7000存储设备上raid5阵列上一块硬盘出现故障离线,热备盘自动启用开始同步数据。热备盘数据同步还没有结束的情况下,与离线盘处于同一组Mdisk中的另一块磁盘离线。热备盘同步失败,该组Mdisk失效,通用卷无法使用。