rdb_bgsave_in_progress=1表示rdb真正在运行，是唯一实时指标；值为0则无bgsave执行。其他bgsave字段仅记录历史，无法反映当前状态。
怎么用 rdb_bgsave_in_progress 判断 RDB 是否真正在跑
rdb_bgsave_in_progress 是唯一能实时反映 RDB 是否正在执行的字段，值为 1 就代表子进程已 fork、正在写盘；值为 0 表示当前没有活跃的 BGSAVE。其他带 bgsave 的字段（比如 rdb_last_bgsave_time_sec、rdb_last_save_time）都只记录历史结果，不能用来判断“此刻是否在运行”。
常见误操作：
- 看到
rdb_last_bgsave_status是ok，就以为“刚跑完”，其实它可能几小时没更新过 - 拿
rdb_last_save_time和当前时间比，算出“距上次已过去 600 秒”，然后断定“RDB 卡了”——但这个字段只在成功时才写入，失败、中断、被 kill 都不会更新
为什么 rdb_bgsave_in_progress 会长时间卡在 1 不变
这说明子进程 fork 成功了，但卡在写文件阶段，父进程无法感知，也不会重置该字段。典型原因包括：
- 磁盘满（
df -h查dir所在分区） - 文件系统只读（
mount | grep $(redis-cli config get dir | awk '{print $2}')） - SELinux 拒绝写入（
ausearch -m avc -ts recent | grep redis） - 挂载了低性能或受限的存储（如 NFS、EBS gp2 突发 I/O 耗尽后）
-
ulimit -n过低导致open()失败，子进程 hang 在系统调用里
验证方式：用 ps aux | grep 'redis-server.*\[bgsave\]' 看是否存在长时间存活的 [bgsave] 进程；有 root 权限时可查 /proc/<pid>/stack</pid> 确认卡在 sys_write 还是 do_sync_read。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
rdb_current_bgsave_time_sec 怎么看才算有效
这个字段只有在 rdb_bgsave_in_progress == 1 时才有意义，它表示当前 BGSAVE 已持续的秒数。若它持续增长且超过 300 秒，而 rdb_last_bgsave_status 仍为 ok 或未变，基本可以判定子进程 I/O 卡死。
注意：
- 它不是累计值，每次新
BGSAVE启动就会重置为 0 - 若
rdb_bgsave_in_progress == 0，该字段值为-1，此时忽略它 - 它不包含 fork 时间，只统计子进程开始写盘后的耗时
仅靠 INFO persistence 不足以定位失败原因
rdb_last_bgsave_status: err 只是一个终点提示，不带任何上下文。Redis 日志才是关键入口，但默认 loglevel notice 会过滤掉多数 I/O 错误信息。必须将日志级别设为 verbose 或 debug 才能看到类似 Failed to open RDB file: Permission denied 或 write(2) failed: No space left on device 的真实报错。
容易被忽略的一点：rdb_last_cow_size 值异常高（比如远超 used_memory），往往意味着写时复制开销巨大，可能加剧 I/O 压力，间接拖慢 BGSAVE —— 这个字段在排查长耗时场景时值得顺手扫一眼。
