手动触发aof重写唯一安全命令是bgrewriteaof，它在后台子进程执行、不阻塞主线程，新文件写完后原子替换旧文件，期间客户端写入同时追加至新旧aof文件。

手动触发AOF重写用 BGREWRITEAOF，不是“压缩”命令

Redis 没有独立的 AOF COMPRESS 或 AOF REWRITE 命令；所谓“AOF压缩”，实际就是 AOF 重写（rewrite），本质是生成一个更小、等价的新 appendonly.aof 文件。唯一安全的手动方式是执行 BGREWRITEAOF —— 它在后台子进程完成，不阻塞主线程。

常见错误是误用 SAVE 或直接修改文件，这会导致数据不一致甚至服务不可用。

• BGREWRITEAOF 是原子操作：新文件写完后才原子替换旧文件，期间客户端写入持续生效（新旧 AOF 同时追加）
• 不能在 RDB BGSAVE 正在运行时立刻触发 BGREWRITEAOF：Redis 会排队等待，但不会报错；可通过 INFO persistence 查看 aof_rewrite_in_progress 是否为 1
• 如果配置了 no-appendfsync-on-rewrite yes，重写期间新写入暂存缓冲区，宕机可能丢失最多 1 秒数据（取决于 appendfsync 设置）

触发前必须确认 appendonly yes 已启用

执行 BGREWRITEAOF 前，Redis 必须处于 AOF 模式，否则命令返回 (error) ERR Background append only file rewriting is not enabled。这不是连接或权限问题，而是配置缺失。

检查方式：

redis-cli CONFIG GET appendonly

若返回 1) "appendonly" 2) "no"，需先启用：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 临时启用（重启失效）：CONFIG SET appendonly yes
• 永久启用：编辑 redis.conf，设 appendonly yes，然后 CONFIG REWRITE 持久化配置变更
• 注意：启用后首次启动会自动加载现有 AOF 文件；若文件损坏，需先用 redis-check-aof --fix 修复

重写失败的典型现象和排查点

命令返回 OK 只代表任务已提交，不代表成功完成。真正失败往往静默发生，表现为磁盘空间没释放、INFO persistence 中 aof_current_size 长期不变。

• 查看日志：tail -f /var/log/redis/redis-server.log，搜索 Background AOF rewrite terminated with success 或 failed
• 磁盘空间不足：重写需临时空间 ≈ 当前数据集内存占用 + 少量开销；若 /tmp 或 Redis dir 所在分区剩余空间
• 内存不足导致 fork 失败：子进程需 copy-on-write 内存页，物理内存紧张时 fork() 返回失败，日志中会出现 Can't fork for AOF rewrite: Cannot allocate memory
• 权限问题：Redis 进程对 dir 目录无写权限，或 appendfilename 指定路径含非法字符/过长路径

重写后验证新 AOF 文件是否有效

重写完成不等于可安全删旧文件。必须确认新文件能被正确加载，否则重启可能丢数据。

验证步骤（停机窗口极短）：

• 停止写入（如运维窗口）：redis-cli CONFIG SET stop-writes-on-bgsave-error no 不起作用，应改用 redis-cli CLIENT PAUSE 10000 WRITE
• 强制同步缓冲区：redis-cli CONFIG SET appendfsync always → 等几秒 → 改回 everysec
• 用 redis-check-aof --fix 校验新文件：redis-check-aof --fix /var/lib/redis/appendonly.aof
• 启动一个临时 Redis 实例加载它：redis-server --appendonly yes --appendfilename appendonly.aof --dir /tmp/testaof，再 redis-cli -p 6380 DBSIZE 对比原实例数据量

真实生产环境里，重写本身不难，难的是验证与回滚预案——尤其当 AOF 文件超 GB 级、重写耗时数分钟时，跳过验证直接上线，等于把恢复希望押在“它应该没问题”上。