rdb_bgsave_in_progress是唯一实时反映RDB是否正在执行的字段；rdb_last_save_time为上次成功时间戳；rdb_last_bgsave_status仅记录最近一次结果（ok/err），不体现过程。
INFO Persistence里哪些字段对应RDB保存状态
Redis 的 INFO Persistence 输出中，真正反映 RDB 持久化执行状态的只有几个关键字段，不是所有带 “bgsave” 的都实时有效。rdb_bgsave_in_progress 是唯一能即时判断当前是否有 SAVE 或 BGSAVE 正在运行的布尔值；rdb_last_save_time 是上一次成功完成的时间戳（秒级），不是开始时间；rdb_last_bgsave_status 只记录最近一次结果（ok 或 err），不反映中间过程。
常见错误现象：看到 rdb_last_bgsave_time 很久没更新，就以为 RDB 卡住了——其实它只在成功时才写入，失败或被中断都不会更新，不能用来判断“是否正在执行”。
-
rdb_bgsave_in_progress为1才代表真正在 fork + 写盘 -
rdb_last_bgsave_status是err时，必须结合redis.log查具体错误（比如磁盘满、fork 失败、权限不足） -
rdb_last_bgsave_time和unixtime对比，可算出距上次成功多久，但无法反推本次是否超时
为什么rdb_bgsave_in_progress有时卡在1不动
这个字段卡在 1 不变，大概率是子进程卡在写文件阶段，而不是 fork 阶段。Redis fork 后，父进程立刻返回，rdb_bgsave_in_progress 就设为 1；但子进程实际写 RDB 文件可能因 I/O 延迟、磁盘打满、文件系统锁、SELinux 限制等卡住，此时父进程无法感知，也就不会重置该字段。
典型场景：云主机挂载的网络盘（如 AWS EBS gp2 在突发 I/O 耗尽后）、容器内挂载的 NFS 卷、或 ulimit -n 设置过低导致 open() 失败但未及时退出。
- 用
ps aux | grep redis看是否存在redis-server *:6379 [bgsave]进程且长时间存在 - 检查
/proc/<pid>/stack（需 root）确认子进程卡在哪个系统调用（如sys_write、do_sync_read） - 对比
redis-cli info stats | grep expired和redis-cli info memory | grep mem，若expired_keys暴涨或used_memory_rss远大于used_memory，可能是内存碎片+写放大加剧 I/O 压力
INFO Persistence不显示失败原因，怎么快速定位bgsave err
INFO Persistence 里的 rdb_last_bgsave_status:err 是个终点提示，不是诊断入口。它不包含 errno、路径、或上下文，必须依赖外部线索交叉验证。
最直接的方式是查 Redis 日志——但要注意默认日志级别是 notice，fork 失败、write 错误等关键信息只在 verbose 或 debug 级别输出。生产环境一般不开 debug，所以得提前配置好。
- 临时提级日志：
redis-cli config set loglevel verbose，再触发一次bgrewriteaof或save观察 - 检查
rdb_last_bgsave_time和redis-cli time差值，若接近timeout配置（如 60 秒），很可能是 write 阻塞超时 - 确认
dir配置路径是否可写：redis-cli config get dir→ 在对应目录下touch test.$$ && rm test.$$ - 注意
stop-writes-on-bgsave-error yes开启时，写入会直接拒绝，此时redis-cli info stats | grep rejected会非零
监控脚本里别只看rdb_last_bgsave_time是否更新
很多运维脚本用 rdb_last_bgsave_time 和当前时间差是否超阈值来告警，这会漏掉“一直在执行但卡死”的情况。真正可靠的监控组合是：rdb_bgsave_in_progress == 1 持续超过 300 秒，且 rdb_last_bgsave_status == ok 长期未变——前者说明卡在写盘，后者说明没有新成功记录兜底。
另外，INFO Persistence 本身不包含耗时统计，Redis 也不暴露单次 bgsave 的 wall clock 时间。想量化性能，只能靠外部计时器 wrap redis-cli save，或者用 strace -p <redis-pid> -e trace=write,fsync 抓系统调用耗时（仅调试用）。
- 告警逻辑应同时检查：
rdb_bgsave_in_progress和rdb_last_bgsave_status的组合状态 - 避免用
rdb_changes_since_last_save做 RDB 触发依据——它只在save配置项触发时递增，手动bgrewriteaof或save不影响它 - 如果用 Redis 6.0+，可开启
activedefrag，但注意内存碎片整理会显著延长 bgsave 子进程生命周期，监控阈值要相应放宽
真正难的是区分“慢”和“死”：一个花了 400 秒的 bgsave，可能是大实例配了慢盘，也可能是卡死。得靠 ps + /proc/pid/stack + iostat -x 1 三者对齐才能下结论。
