redis-check-aof 返回“Ok”说明AOF文件语法完整、无截断，可被Redis正常重放；需用绝对路径执行，避免旧版本误用，且不可在Redis运行时校验。
怎么用 redis-check-aof 判断 AOF 文件是否可加载
redis-check-aof 是 Redis 自带的唯一权威校验工具，它不依赖 Redis 进程运行，直接解析 appendonly.aof 的 RESP 帧结构。只要返回 Ok，说明文件语法完整、末尾无截断，能被 Redis 正常重放。
常见误判点：工具输出 AOF analyzed: ... The first error is at byte offset XXX 时，很多人直接删掉出错位置之后的内容——这极可能丢数据。正确做法是先备份原文件，再用 --fix 尝试自动修复（仅对尾部截断有效）。
- 执行命令必须加绝对路径，避免因 PATH 不一致调用到旧版本：
/usr/local/bin/redis-check-aof /var/lib/redis/appendonly.aof - 若输出含
Truncated AOF file，且aof-load-truncated yes已启用，Redis 启动时会跳过损坏部分，但日志里一定有警告，脚本需 grep 捕获 - 不要在 Redis 运行时校验——AOF 可能正被写入，导致校验结果不准；应先
redis-cli BGREWRITEAOF触发重写，等新文件生成后再校验旧文件
如何从 INFO persistence 提取 AOF 异常信号
INFO persistence 不显示磁盘剩余空间，但它暴露的字段组合是 AOF 即将崩溃的早期红灯。单看某个值没意义，要交叉比对。
关键字段组合逻辑：
-
aof_rewrite_in_progress:1且aof_last_bgrewrite_status:err→ 上次重写失败，大概率是No space left on device -
aof_pending_rewrite:1且aof_current_size持续增长 → 重写被挂起，磁盘已满或 fork 失败 -
aof_base_size和aof_current_size比值长期 > 200%，但aof_rewrite_in_progress:0→auto-aof-rewrite-percentage配得太死，或重写被退避
Shell 脚本中建议用这一行提取关键值：redis-cli INFO persistence | awk -F':' '/aof_current_size|aof_base_size|aof_rewrite_in_progress|aof_last_bgrewrite_status|aof_pending_rewrite/ {print $1,$2}'
为什么 watch + grep aof_current_size 容易漏掉真问题
单纯监控 aof_current_size 的数值增长，就像只看体温不查血常规——它告诉你“在变大”，但不告诉你是正常写入还是失控膨胀。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
真实风险场景往往伴随其他指标静默异常：
- 业务写入量没变，
aof_current_size却每小时涨 2GB → 很可能是maxmemory设为 0，大量过期键未清理，AOF 仍记录 SET+EXPIRE 命令 -
aof_rewrite_in_progress:1持续超过 5 分钟 → 查df -h会发现磁盘 99%，临时重写文件temp-rewriteaof-*卡在写入中途 -
aof_last_bgrewrite_status:ok，但aof_current_size比aof_base_size小 → 重写成功了，但新文件没被原子替换（常见于dir权限不足或 SELinux 限制）
所以脚本里别只做 if [ $size -gt $threshold ]，要加条件：if [ "$rewrite_status" = "err" ] || [ "$pending" = "1" ] || [ $size_ratio -gt 300 ]
脚本里怎么安全触发自动修复而不误删数据
redis-check-aof --fix 只修复尾部截断，对中间损坏无效，且修复后文件大小会缩小——这意味着丢失部分命令。生产环境脚本必须设防。
执行前必做三件事：
- 用
cp -p appendonly.aof appendonly.aof.$(date +%s)打时间戳备份，保留至少 3 份历史 - 检查
du -h appendonly.aof和redis-cli INFO persistence | grep aof_current_size是否一致，不一致说明文件正被写入或已损坏 - 修复后必须验证：用
redis-check-aof --fix输出的“OK”不能当终点，要再跑一次redis-server --test-memory 2确保内存无 corruption，再尝试redis-cli PING
最易被忽略的一点：修复后的 AOF 文件权限可能变成 root:root，而 Redis 进程以 redis 用户运行，启动时会因权限拒绝加载——脚本末尾务必加 chown redis:redis appendonly.aof
