怎样解决Redis主从切换后AOF文件不一致问题_同步Master节点的持久化配置

主从切换后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秒数据。

如何验证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 后，应立刻看到 *3rn$3rnSETrn$7rntestkeyrn$3rnabcrn 类似内容

若 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 路径若指向通用片段，该片段里不能包含任何持久化指令；所有角色敏感项必须在主/从模板顶层显式声明，避免继承污染。