Redis RDB 快照失败时怎么从 lastsave 判断结果

Redis 的 RDB 快照出现“失败”时，先不要只看一眼 LASTSAVE 就下结论。LASTSAVE 返回的是最近一次成功写盘的 Unix 时间戳；它不会直接告诉你当前的 BGSAVE 是否正在运行，也不会单独给出失败原因。正确做法是记录旧值、发起快照、轮询新值，再把结果和 INFO persistence、Redis 日志对上。

如果 LASTSAVE 在一次 BGSAVE 后变大，说明出现了新的成功 RDB 写盘；如果暂时不变，只能说明“还没有观察到新的成功保存”，不能立即等同于失败。

一、LASTSAVE 记录的是什么，为什么会误判

官方命令语义很明确：LASTSAVE 返回数据库最近一次成功保存到磁盘的时间。Redis 启动时也会把数据库视为已经保存，因此刚启动的实例可能马上返回一个时间值。

这带来一个常见误区：运维脚本发出 BGSAVE 后读取到一个旧的时间戳，就把它当成“快照失败”。其实后台保存可能还没结束；反过来，如果上一次快照成功过，即使这一次保存失败，LASTSAVE 仍然可能保留旧值。这个字段适合确认“最近一次成功结果”，不适合代替任务状态。

二、先记录基线，再发起一次 BGSAVE

排查的第一步是保存发起快照前的 LASTSAVE，同时记录 BGSAVE 的直接返回。示例中的变量只用于演示判断边界，不会改变 Redis 配置。

# 读取发起快照前的成功保存时间
before=$(redis-cli LASTSAVE)

# 请求后台生成 RDB；返回值只能说明请求是否被接受
reply=$(redis-cli BGSAVE)
printf '基线=%s，BGSAVE返回=%s\n' "$before" "$reply"

# 读取一次当前状态，避免把旧时间误报成新快照
redis-cli INFO persistence | grep -E 'rdb_bgsave_in_progress|rdb_last_bgsave_status'

如果返回提示已有后台保存任务，先把它视为“当前已有任务”，不要立刻再次触发。BGSAVE 的返回和后续状态字段回答的是任务层问题，而 LASTSAVE 回答的是结果层问题。

三、轮询 LASTSAVE 是否真的前进

基线拿到后，按固定间隔读取 LASTSAVE。新值大于基线，才能把本轮判断为出现了新的成功写盘；等值则表示尚未观察到成功完成。轮询间隔和最大等待时间应按 RDB 文件大小、磁盘速度设定，不能用一次瞬时读取代替等待。

# 轮询最多 30 秒；生产脚本应按实例规模调整上限
for i in $(seq 1 15); do
  current=$(redis-cli LASTSAVE)
  if [ "$current" -gt "$before" ]; then
    echo '检测到新的成功 RDB 保存'
    break
  fi

  # 先等待后台任务推进，再读取下一次时间戳
  sleep 2
done

脚本超时后不要输出“快照失败”这一种结论，而应输出“在等待窗口内没有观察到新的成功保存”，并进入下一层排查。否则一次磁盘繁忙或快照较大的正常延迟，就会变成误报警。

四、用 INFO persistence 把结果补完整

INFO persistence 能补上 LASTSAVE 缺少的实时上下文。重点看三个字段：

“进行中为 1、LASTSAVE 未变化”是等待状态；“进行中为 0、最后状态为 err、LASTSAVE 仍旧”才更接近失败，需要继续看 Redis 日志中的磁盘空间、权限、路径或 fork 相关错误。若状态为 ok 且时间戳已前进，才完成了本轮成功确认。

五、生产环境采用三层判定

监控可以把判定拆成三层：第一层是任务状态，确认是否仍在保存；第二层是结果状态，确认最近一次后台保存是成功还是错误；第三层是新鲜度，比较 LASTSAVE 与本轮基线的差异。三层中任何一层缺失，都不适合直接宣布“快照成功”。

告警消息最好带上基线时间、当前时间、rdb_bgsave_in_progress、rdb_last_bgsave_status 和日志摘要。这样值班人员能区分“还在生成”“已经失败”和“任务成功但监控读到了旧实例”三种完全不同的情况。Redis 官方文档的命令页也建议在发起 BGSAVE 后按间隔检查 LASTSAVE 是否变化；实际系统再用状态字段和日志补充原因即可。

常见问题

LASTSAVE 一直不变就一定是 RDB 失败吗？

不一定。可能仍在进行，也可能本轮请求没有被接受，或者保存已经失败。先看 rdb_bgsave_in_progress 和 rdb_last_bgsave_status。

为什么不能只看 rdb_last_bgsave_status？

它更接近最近一次后台保存的结果，但仍要结合本轮基线和时间戳，才能证明这次请求产生了新的成功文件。

排查快照失败时要不要立刻重试 BGSAVE？

不要盲目重试。先确认是否已有任务、记录错误日志并检查磁盘和目录权限；否则可能让故障现象更难还原。