rdb_bgsave_in_progress是唯一能实时判断RDB是否正在执行的字段；若其值为1且rdb_current_bgsave_time_sec持续增长（如超300秒）而rdb_last_bgsave_status未变，说明bgsave卡住，常见原因为磁盘满、文件系统只读或SELinux限制。
rdb_bgsave_in_progress 是唯一能实时判断 RDB 是否正在执行的字段，其他带 “bgsave” 的指标都不反映当前过程。
怎么用 INFO persistence 判断 RDB 是否卡住
直接执行 INFO persistence，重点看三个字段：rdb_bgsave_in_progress、rdb_current_bgsave_time_sec、rdb_last_bgsave_status。如果 rdb_bgsave_in_progress 为 1，但 rdb_current_bgsave_time_sec 持续增长（比如超过 300 秒），而 rdb_last_bgsave_status 仍是 ok 或没变，说明子进程可能卡在 I/O（如磁盘写满、ext4 journal hang、SELinux 拒绝写入）；此时父进程无法感知，字段也不会自动清零。
常见误判点：
-
rdb_last_bgsave_time_sec只记录上一次成功耗时，和当前无关 -
rdb_last_save_time是时间戳，不是持续时间，不能用来算“这次跑了多久” -
rdb_last_bgsave_status仅更新最后一次结果，哪怕当前卡死，它也不会变成err
为什么 rdb_bgsave_in_progress=1 却迟迟不结束
Redis 执行 BGSAVE 时，fork 完就设 rdb_bgsave_in_progress=1，后续完全依赖子进程。子进程卡住的典型原因包括：
- 磁盘空间不足或 inodes 耗尽（
df -h和df -i都要查） - 文件系统处于只读状态（
mount | grep "ro"） - 内核日志出现
EXT4-fs error或writeback: page writeback failed - SELinux 启用且策略限制了
redis-server的文件写权限（ausearch -m avc -ts recent查拒绝日志） - 子进程 stuck 在
sys_write或do_sync_read（需 root 查/proc/<pid>/stack</pid>）
INFO persistence 中容易被忽略的关键组合
单看一个字段意义有限，必须交叉验证：
-
rdb_changes_since_last_save > 0且rdb_bgsave_in_progress = 0：说明有写入但没触发持久化，检查是否配置了save规则（如save 900 1）未满足，或被禁用 -
loading = 1时，rdb_bgsave_in_progress必为 0 —— 加载期间禁止 BGSAVE，否则会冲突 -
aof_rewrite_in_progress = 1且rdb_bgsave_in_progress = 1：极罕见，说明同时跑两个 fork 子进程，内存压力陡增，可能触发 OOM killer -
rdb_last_cow_size突然飙升：说明 fork 后父进程修改大量页，导致 copy-on-write 开销剧增，RDB 写入延迟升高
真正难排查的不是“有没有在保存”，而是“为什么停在那儿不动”。rdb_bgsave_in_progress 是开关，rdb_current_bgsave_time_sec 是秒表，但秒表不会自己报警——得靠外部线索（磁盘、内核、SELinux）来定位卡点。
