一次 Redis MISCONF 故障，背后竟是磁盘 I/O 异常

前言

昨天碰到一个 Redis 故障，应用突然报错，提示 Redis 无法写入。

一开始看到 MISCONF，以为就是常见的 RDB 持久化失败。之前也遇到过类似问题，大部分都是磁盘空间不足，清理一下空间或者处理持久化目录就能恢复。

结果排查下来发现，这次还不太一样：Redis 所在服务器的磁盘空间还剩 400 多 GB，内存也没什么压力，Redis 进程一直在，但就是无法写入。

继续查下去才发现 Redis 的 RDB 文件和日志都停留在了 9 月 30 日，记得当时是工厂断电导致虚拟化重启了，这台主机恰好是运行在虚拟化上，应该是那时候导致的问题，而今天已经是 10 月 13 日，看来这台 Redis 服务器可能也没那么重要。

顺着这个时间点往下查，最后才发现，真正出问题的不是 Redis，而是 Linux 的根文件系统。

本文记录一下这次排查过程。

一、应用突然报 Redis MISCONF

最开始是应用服务器报错，Java 日志中出现大量 Redisson 异常，核心报错如下：

1org.redisson.client.RedisException:
2MISCONF Redis is configured to save RDB snapshots,
3but it is currently not able to persist on disk.
4
5Commands that may modify the data set are disabled,
6because this instance is configured to report errors
7during writes if RDB snapshotting fails.

Redis 地址是 10.235.39.27:6379，这个报错其实比较明确。

Redis 配置了 RDB 持久化，但是当前无法将快照保存到磁盘。由于开启了 stop-writes-on-bgsave-error 保护机制，Redis 会拒绝可能修改数据的命令。

一般遇到这种情况，我会先看以下几个地方：

1. 磁盘是不是满了
2. Redis 数据目录有没有权限
3. 内存是否充足
4. RDB 保存到底报了什么错

先登录服务器看看。

二、磁盘空间正常，Redis 进程也在

登录 Redis 服务器，先检查系统资源：

1df -h
2df -i
3free -h
4ps -ef | grep '[r]edis-server'

磁盘情况：

1Filesystem                         Size  Used Avail Use%
2/dev/mapper/ubuntu--vg-ubuntu--lv  490G  7.2G  463G   2%

490G 的根分区，只用了 7.2G，剩余 463G，inode 使用率只有 1%，也没什么问题。

再看内存：

1              total    used    free    available
2Mem:          7.8Gi    278Mi   6.9Gi   7.2Gi
3Swap:         4.0Gi      0B    4.0Gi

系统内存也很充足。

Redis 进程正常：

1redis 969 1 /usr/bin/redis-server *:6379

这就有点奇怪了。

磁盘没满，内存正常，Redis 进程也没有退出，为什么 RDB 会保存失败？

本来准备直接查 Redis 的持久化状态：

1redis-cli -p 6379 INFO persistence

结果返回：

1NOAUTH Authentication required.

Redis 开启了密码认证，现场暂时没有拿到密码。

既然 Redis 内部状态暂时查不了，那就先从操作系统和配置文件继续排查。

三、RDB 文件竟然停留在十几天前

先查看 Redis 的持久化配置：

1grep -En \
2'^[[:space:]]*(dir|dbfilename|save|appendonly|logfile)[[:space:]]' \
3/etc/redis/redis.conf
4
5save 900 1
6save 300 10
7save 60 10000
8
9dbfilename dump.rdb
10dir /var/lib/redis
11appendonly no

配置比较常规，启用了 RDB，没有开启 AOF。

接着检查 RDB 文件：

1ls -lh --full-time /var/lib/redis/
2
3-rw-rw---- 1 redis redis 11M
42026-09-30 19:26:03 dump.rdb

看到这里就感觉不太对了。

当天是 10 月 13 日，RDB 文件最后更新时间却是 9 月 30 日，已经过去十几天了。

按当前配置，只要满足相应的数据变更条件，Redis 就会尝试生成 RDB 快照。正常情况下，业务持续使用 Redis，不应该这么长时间都没有新的快照。

当然，单凭文件时间还不能直接判断持久化失败，毕竟还要看期间有没有数据变更。

继续检查 Redis 日志：

1tail -100 /var/log/redis/redis-server.log

发现日志也停留在了 9 月 30 日。

最后几条记录：

130 Sep 2026 19:26:03
2Background saving terminated with success
3
430 Sep 2026 19:41:04
51 changes in 900 seconds. Saving...

19:26 的 RDB 保存还是成功的，19:41 又触发了一次保存，但后面没有看到对应的成功记录。

而且 Redis 日志也没有继续更新，两个文件都停留在同一天，这就值得注意了。

如果只是 Redis RDB 保存失败，正常情况下日志里应该能找到一些错误信息。但现在连日志都不更新了，是不是文件系统本身出了问题？

四、Redis 目录权限正常，却无法写入

先检查 Redis 数据目录权限：

1ls -ld /var/lib/redis
2ls -lh /var/lib/redis/
3
4drwxr-x--- redis redis /var/lib/redis
5-rw-rw---- redis redis dump.rdb

Redis 进程本身就是使用 redis 用户运行的，目录属主和权限看起来都没有问题。

再检查一下完整路径：

1namei -l /var/lib/redis/dump.rdb

也没发现明显异常。

那就直接测试一下 redis 用户能不能写：

1sudo -u redis test -w /var/lib/redis \
2  && echo "DATA WRITABLE" \
3  || echo "DATA NOT WRITABLE"
4
5DATA NOT WRITABLE

再测试日志文件：

1sudo -u redis test -w /var/log/redis/redis-server.log \
2  && echo "LOG WRITABLE" \
3  || echo "LOG NOT WRITABLE"
4
5LOG NOT WRITABLE

这下有意思了。

Redis 用户明明拥有数据目录和日志文件的写入权限，但实际检查却显示无法写入。如果只是普通权限问题，通常能从属主、权限位或者 ACL 中找到原因。

但这里都没发现明显异常。

于是继续检查文件系统的挂载状态：

1findmnt -T /var/lib/redis -o TARGET,SOURCE,FSTYPE,OPTIONS
2
3TARGET SOURCE                            FSTYPE OPTIONS
4/      /dev/mapper/ubuntu--vg-ubuntu--lv ext4   ro,relatime

看到 ro，问题一下就清楚了。

根文件系统已经变成只读了。

正常情况下应该是 rw，现在却是 ro，难怪 Redis 无法保存 RDB，日志也无法继续写入。

之前一直在检查 Redis 目录权限，实际上根本不是目录权限的问题，而是整个根文件系统都不允许写入了。不过问题还没结束，Linux 为什么会把根文件系统切换成只读？

五、查内核日志，终于找到根因

既然文件系统已经只读，那就得查一下内核日志：

1journalctl -k --since "2026-09-30" \
2  --no-pager | \
3grep -Ei 'I/O error|EXT4-fs|read-only|remount'

这一查，问题就出来了。

日志中出现大量磁盘 I/O 错误：

1blk_update_request: I/O error, dev sda
2
3EXT4-fs warning (device dm-0):
4I/O error writing to inode
5
6Buffer I/O error on device dm-0

继续往下看：

1EXT4-fs error (device dm-0):
2Detected aborted journal

EXT4 的 Journal 已经异常中止。

更关键的是下面这条：

1Sep 30 20:27:24
2EXT4-fs (dm-0):
3Remounting filesystem read-only

时间终于对上了，9 月 30 日 20:27:24，Linux 明确记录了将根文件系统重新挂载为只读的操作。

而在此之前，磁盘已经出现大量 I/O 超时：

1sd 2:0:0:0: [sda]
2timing out command, waited 1080s

1080 秒，整整 18 分钟。部分磁盘读写请求等待了这么长时间，最后还是失败了。

后面又陆续出现超级块写入失败：

1EXT4-fs (dm-0):
2I/O error while writing superblock

到这里，整个问题基本串起来了：

1. 9 月 30 日，底层磁盘出现 I/O 异常，导致 EXT4 Journal 中止，Linux 将根文件系统切换为只读。
2. Redis 的 RDB 文件和日志都放在根文件系统上，自然也就无法继续写入。
3. 等到应用触发 Redis 写操作时，就出现了最开始看到的 MISCONF。

所以这次 Redis 报错，实际上只是底层存储故障在应用层的表现。

六、再看磁盘，发现根文件系统跨了两块盘

继续确认服务器环境：

1systemd-detect-virt
2
3vmware

这是一台 VMware 虚拟机。

再看磁盘结构：

1lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS,RO,TYPE
2
3sda                         100G
4├─sda1                        1M
5├─sda2                        2G ext4 /boot
6└─sda3                       98G LVM2_member
7  └─ubuntu--vg-ubuntu--lv   498G ext4 /
8
9sdb                         400G LVM2_member
10└─ubuntu--vg-ubuntu--lv     498G ext4 /

这里还有个需要注意的地方。

这台服务器的根文件系统使用了 LVM，而且跨了两块虚拟磁盘，一块 100G，一块 400G，最终组成了一个约 498G 的逻辑卷。

前面内核日志中的错误主要指向 /dev/sda，也就是说，即使另一块磁盘正常，只要其中一块出现 I/O 问题，就可能影响整个根文件系统。

当然，虚拟机内部看到 /dev/sda 报错，不代表一定是物理磁盘损坏。

还需要 VMware 管理员检查对应的 VMDK、Datastore、ESXi 存储路径等，才能进一步确认底层到底发生了什么。

七、虚拟机重启，Redis 恢复启动

找到问题后，原本准备继续检查 VMware 存储，再考虑文件系统修复。

不过在处理过程中，VMware 管理员已经直接重启了虚拟机，重启过程还卡了一会儿。

控制台一直显示：

1A stop job is running for Advanced key-value store
2(5min 17s / no limit)

这里的 Advanced key-value store 就是 Redis，说明 systemd 一直在等待 Redis 服务停止。

至于 Redis 为什么迟迟没有退出，当时没有进一步拿到进程状态，不能直接判断是 RDB 保存卡住，还是底层 I/O 导致的阻塞。

后来虚拟机总算完成了重启。

重新登录后，先检查系统启动时间：

1uptime
2who -b
3
4system boot 2026-10-13 14:52

再看根文件系统：

1findmnt /
2
3TARGET SOURCE                            FSTYPE OPTIONS
4/      /dev/mapper/ubuntu--vg-ubuntu--lv ext4   rw,relatime

这次已经恢复成 rw 了。

检查本次启动的内核日志，也没有发现新的磁盘 I/O 错误。

再看 Redis：

1systemctl status redis-server --no-pager
2
3Active: active (running)
4Status: "Ready to accept connections"

Redis 在 14:53 正常启动，6379 端口也已经监听。

1ss -lntp | grep 6379
2
3LISTEN 0 511 0.0.0.0:6379

到这里，操作系统和 Redis 服务都已经重新起来了。

不过重启后检查发现，dump.rdb 仍然是 9 月 30 日的文件。因为这套 Redis 主要用于缓存，业务数据可以重新加载，所以这次没有强求恢复 9 月 30 日之后的缓存内容。

需要说明的是，现场最后还没有完成 Redis 认证后的 SET/GET 和 INFO persistence 验证，因此目前能确认的是系统恢复读写、Redis 服务正常启动，不能仅凭进程状态就认定 Redis 写入和 RDB 持久化全部恢复。

最后

这次 Redis 故障，表面上是 RDB 持久化失败，实际上是底层磁盘 I/O 异常导致 EXT4 文件系统变成了只读。

排查过程中有个细节值得注意：磁盘空间充足，不代表文件系统就能正常写入。

以后再遇到类似的 MISCONF，除了检查 Redis 持久化状态和磁盘空间，也可以顺手看一下文件系统：

1findmnt /
2dmesg -T | grep -Ei 'I/O error|EXT4-fs|read-only'

另外，这次重启后虽然系统恢复了读写，Redis 也正常启动，但 VMware 底层存储问题还需要进一步确认，不能因为服务起来了就认为故障彻底解决。