解决Redis主从切换后AOF不一致：同步主节点持久化配置

先说核心结论：主从切换后AOF“突然失效”，这事儿跟文件损坏没关系。真正的祸根在于配置继承——新主库一头扎进了原从库的appendonly no里，根本就不落盘。

故障转移发生时，被哨兵或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写入线程要么卡住，要么被禁用了。

生产环境配置模板必须分角色管理

所有节点共用同一份配置模板，是这条线上最大的隐患。正确的做法是维护两套基础配置，各司其职：

• 主库模板：包含sa ve规则、appendonly yes、appendfsync everysec、no-appendfsync-on-rewrite yes。
• 从库模板：强制sa ve ""（关掉RDB）、appendonly no、replica-read-only yes，并且禁止任何运行时CONFIG SET来修改这些值。

部署时按角色注入对应模板。记住一条铁律：千万别在从库上临时执行CONFIG SET appendonly yes来启用AOF——这会触发AOF重写，跟复制缓冲区争抢I/O，同步延迟会瞬间飙升甚至直接中断。

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