主从切换后AOF“突然失效”是因为新主库继承原从库配置，appendonly no导致不落盘；必须预设主库模板含appendonly yes、appendfsync everysec、aof-use-rdb-preamble yes三者联动，且禁止从库运行时SET修改。
主从切换后AOF不一致，不是文件损坏，而是配置继承错误——新主库直接沿用原从库的 appendonly no，根本不会落盘。
为什么切换后AOF“突然失效”
哨兵或Cluster执行故障转移时，被提升的从库会加载自己原有的 redis.conf，而不是主库的配置。哪怕主库一直开着 appendonly yes，只要从库配置里是 appendonly no，它升为主库后依然不写AOF——连 appendfilename 和 appendfsync 都不会生效。
常见错误现象：INFO persistence 显示 aof_enabled:0，CONFIG GET appendonly 返回 no，但业务日志里却有大量写入；重启后所有切换期间的数据全部丢失。
- Redis 6.2+ 不会自动修改配置文件，
CONFIG REWRITE也只保存运行时 SET 的值，不覆盖原始appendonly no - 若用容器部署（如 Docker），挂载的配置文件未做角色区分，问题更隐蔽
- 运维手动改完配置忘记
CONFIG REWRITE或重启，导致CONFIG GET和磁盘文件不一致
必须同步的三项AOF配置项
仅改 appendonly yes 不够。主库有效的AOF行为依赖三个联动参数，缺一不可：
-
appendonly yes：开关，必须为yes；从库模板中若为no，切换后即失效 -
appendfsync everysec：推荐值；设为no会丢数，always严重拖慢吞吐；注意它和no-appendfsync-on-rewrite yes必须配对 -
aof-use-rdb-preamble yes：开启后AOF前缀为RDB格式，加载快；但重写仍需全量解析旧AOF，不能省略appendfsync安全设置
漏掉任意一项，都可能导致新主库AOF文件内容不完整、无法加载，或丢失最近1秒数据。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
如何验证AOF已真正启用
不能只看 CONFIG GET appendonly。要确认AOF正在实时工作，得查三项指标：
-
INFO persistence中aof_enabled:1且aof_rewrite_in_progress:0（非重写中） -
ls -l查看aof_filename对应文件，大小应随写入持续增长（不是固定0字节或长时间不变） -
tail -f监控AOF文件末尾，执行SET testkey abc后，应立刻看到*3\r\n$3\r\nSET\r\n$7\r\ntestkey\r\n$3\r\nabc\r\n类似内容
若 aof_current_size 长期卡在初始值，或 aof_buffer_length 持续 > 0 且不下降，说明AOF写入线程卡住或被禁用。
生产环境配置模板必须分角色管理
所有节点共用同一份配置模板是最大隐患。正确做法是维护两套基础配置：
- 主库模板：含
save规则、appendonly yes、appendfsync everysec、no-appendfsync-on-rewrite yes - 从库模板：强制
save ""、appendonly no、replica-read-only yes，且禁止任何运行时CONFIG SET修改
部署时按角色注入对应模板；切勿在从库上 CONFIG SET appendonly yes 临时启用——这会触发AOF重写，与复制缓冲区争抢I/O，导致同步延迟飙升甚至中断。
最易被忽略的一点：配置文件中的 include 路径若指向通用片段，该片段里不能包含任何持久化指令；所有角色敏感项必须在主/从模板顶层显式声明，避免继承污染。
