主从复制必须开启AOF，否则从节点重启后数据丢失；从节点需配置appendonly yes和appendfsync everysec，主节点也建议开启AOF；切换前须等待aof_pending_bio_fsync为0再开放VIP。
主从复制必须开启AOF，否则热备形同虚设
只配了 slaveof 但没开AOF，从节点重启后可能直接变空——因为RDB快照是定时生成的，而主从同步过程中产生的增量命令，若未落盘到AOF文件，一旦从节点宕机再拉起，就只能靠上次RDB恢复，中间所有变更全丢。
实操建议：
- 从节点配置中必须设置
appendonly yes，且推荐用appendfsync everysec（兼顾性能与秒级容灾） - 主节点也建议开启AOF，避免自身宕机后无法精确恢复；但注意：主节点AOF重写（
bgrewriteaof）期间不影响复制，子进程不阻塞主线程 - 禁用RDB不是必须，但若同时启用了RDB和AOF，Redis重启时**优先使用AOF恢复**（只要AOF文件完整），所以RDB可设为辅助备份手段
keepalived切换时，从节点晋升前必须完成AOF刷盘
常见错误现象：redis_master.py 脚本刚执行 slaveof no one 就返回成功，但此时AOF缓冲区里还有未落盘的命令，VIP切过去后客户端立刻写入，新“主”实际数据比旧主少一截。
正确做法是加一道等待逻辑：
- 在
notify_master脚本中，执行slaveof no one后，调用redis-cli -p 6379 config rewrite确保配置落地 - 再用
redis-cli -p 6379 aof-rewrite触发一次重写（可选，但能压缩日志体积） - 最关键一步：轮询
redis-cli -p 6379 info persistence | grep aof_pending_bio_fsync，等返回值为0再开放VIP流量
主从延迟导致AOF内容不一致，怎么识别和应对
AOF本身不解决复制延迟，它只保证单节点写操作可回放。但主从延迟高时，从节点AOF里记录的命令时间线，会明显滞后于主节点——这在故障切换时容易引发数据覆盖或丢失。
判断与缓解方式：
- 用
redis-cli info replication查看master_repl_offset和slave_repl_offset差值，超过10万字节说明延迟已显著 - 从节点开启
repl-disable-tcp-nodelay yes（默认no），减少小包合并带来的延迟，适合局域网低延迟场景 - 不要依赖从节点AOF做主节点的数据补救——它的AOF只是“自己收到的命令副本”，不是主节点原始操作流；真正兜底应靠主节点自身的AOF + 定期RDB备份
无硬盘模式（diskless replication）下，AOF仍需独立配置
有人以为开了 repl-diskless-sync yes 就不用管AOF了，其实不然：diskless只影响RDB传输阶段（主不写磁盘、从不落盘再加载），但AOF日志仍是每个节点独立维护的持久化通道。
特别注意：
- 从节点启用diskless后，
dir配置仍要指向有写权限的路径，因为AOF文件必须落盘 - 若从节点AOF重写（
bgrewriteaof）正在运行，此时触发全量同步，两个子进程会竞争CPU和IO，可能造成卡顿；建议错峰配置auto-aof-rewrite-percentage和save触发条件 - 生产环境慎用
appendfsync no：虽然性能好，但主机断电时从节点AOF可能比主节点还“干净”，反而扩大不一致窗口
真正难的不是配齐AOF+主从，而是理解每条命令在哪个环节落盘、哪个环节进缓冲、哪个环节被丢弃。一个 appendfsync 参数改错，或脚本里少等一次 aof_pending_bio_fsync，热备就变成“冷备”。
