Redis数据丢失排查指南：持久化与AOF检查

Redis数据丢失往往并非真正“丢失”，而是持久化机制根本未生效或悄然失效——90%的案例源于未开启AOF/RDB，或虽配置开启却因权限不足、磁盘写满、AOF重写卡死、appendfsync配置不当等隐性问题导致数据实际未落盘；排查关键在于跳过日志直击运行时状态：用redis-cli config get实时验证AOF/RDB开关与appendfsync策略，结合INFO persistence逐项检查aof_last_write_status、aof_rewrite_in_progress等“生命体征”，再辅以redis-check-aof校验修复，才能揪出那个在内存中无声裸奔的真实原因。

Redis 数据丢失后，第一件事不是翻日志，而是立刻确认它到底有没有开启持久化——90% 的“丢数据”其实是“压根没存过”。

检查 redis.conf 中是否真启用了 AOF 或 RDB

很多人以为 appendonly yes 就万事大吉，但实际配置可能被注释、被覆盖，或只在某个 include 文件里生效。

• 用 redis-cli config get appendonly 查运行时值，不是看配置文件 —— 因为 CONFIG REWRITE 可能没触发，或 systemd 启动时加载了不同配置路径
• 同时查 redis-cli config get save：如果返回空或 ""，说明 RDB 完全禁用；save 900 1 这类规则存在才代表 RDB 在工作
• 注意：AOF 和 RDB 可以共存，但 AOF 优先级更高；若 AOF 开启但写入失败（比如磁盘满），Redis 默认会停止写入并报错 Can't open the append-only file: Permission denied，此时 INFO persistence 里 aof_enabled 是 1，但 aof_last_write_status 为 err

验证 AOF 是否真在落盘：appendfsync 的三种模式差异极大

appendfsync 不是“开/关”开关，而是决定数据从内核缓冲区刷到磁盘的时机，直接影响崩溃时最多丢多少秒数据。

• appendfsync always：每次写都 fsync()，最安全但性能差，适合极低吞吐、强一致性场景
• appendfsync everysec：默认值，每秒刷一次，理论最多丢 1 秒数据；但注意：Linux 的 vm.dirty_ratio 可能让内核延迟刷盘，极端情况下可能多丢几秒
• appendfsync no：完全交给操作系统，可能丢数秒至数十秒 —— 生产环境禁用，除非你明确接受这个风险
• 检查当前值：redis-cli config get appendfsync；若为 no，且发生过断电或 kill -9，基本可判定丢失范围在最近几秒到几十秒之间

确认 AOF 文件是否被截断或损坏

AOF 文件不是数据库快照，而是命令日志。它可能因异常终止而处于不完整状态，Redis 启动时会尝试自动修复，但有时会静默截断到最后一个完整命令。

• 启动 Redis 时加 --loglevel verbose，观察日志中是否有 Reading RDB preamble from AOF file... 或 Failed to open the AOF file
• 用 redis-check-aof --fix appendonly.aof 手动校验并修复（操作前务必备份原文件）
• 修复后对比 redis-cli info persistence | grep aof_current_size 和文件系统大小：若差距过大，说明有大量无效内容或修复失败
• 特别注意：如果 AOF 开启但 aof_rewrite_in_progress 长时间为 1，重写卡住可能导致新命令无法追加，表现为写入成功但重启后消失

真正棘手的不是 AOF 没开，而是它开了却没生效——比如权限不足导致写入失败、磁盘满后 AOF 停摆、或重写进程僵死。这些情况不会报错到业务层，只会让 Redis 在后台悄悄变成纯内存运行。排查时别只盯命令结果，得看 INFO persistence 里的每个字段是否“活”着。

以上就是《Redis数据丢失排查指南：持久化与AOF检查》的详细内容，更多关于的资料请关注golang学习网公众号！