同步Master持久化配置，解决Redis主从切换后AOF不一致

首先给出核心结论：Redis 主从切换后 AOF 功能“突然失效”，问题根源并非文件损坏。真正的罪魁祸首是配置继承机制——晋升为主库的节点沿用了原从库的 appendonly no 配置，导致持久化功能完全关闭。

当故障转移发生时，由哨兵或 Redis 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：AOF 功能总开关，必须设置为 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 ""（禁用 RDB 持久化）、appendonly no、replica-read-only yes，并禁止通过运行时 CONFIG SET 命令修改这些关键参数。

部署时按照节点角色注入对应的配置模板。请牢记一条核心原则：绝对不要在从库上临时执行 CONFIG SET appendonly yes 来启用 AOF——这会立即触发 AOF 重写操作，与复制缓冲区争抢 I/O 资源，导致同步延迟急剧升高甚至直接中断。

还有一个容易被忽视的细节：配置文件中的 include 路径如果引用了通用配置片段，该片段内绝对不能包含任何持久化相关的指令。所有与角色强相关的配置参数，必须直接在主库/从库模板的顶层显式声明，避免被配置继承逻辑“污染”。