redis哨兵切换后数据回滚本质是aof优先恢复逻辑导致：只要appendonly yes且aof文件存在且校验通过，就完全忽略rdb，即使aof内容陈旧或未同步完成；若aof损坏则启动失败，需手动修复，否则无法fallback到rdb。
哨兵切换后数据回滚，本质是AOF/RDB恢复逻辑冲突
Redis 哨兵完成主从切换后出现“数据回滚”，不是哨兵本身的问题，而是新主节点启动时加载持久化文件的顺序和内容不一致导致的。关键点在于：AOF 优先级高于 RDB，但若两者开启状态不统一、或 AOF 文件损坏/截断/未同步完成，就会加载出旧快照甚至空数据。
为什么AOF开启但实际没生效，却仍触发AOF恢复？
即使你配置了 appendonly yes，AOF 也不一定真正记录了最新写入——常见于以下情况：
-
appendfsync no：系统仅依赖内核缓冲刷盘，宕机或进程异常退出时，缓冲区命令全丢，但 Redis 启动时仍尝试加载这个“不完整”的appendonly.aof文件，结果比 RDB 还旧 -
appendfsync everysec（默认）：最多丢失 1 秒数据，但若刚好在刷盘前主节点崩溃 + 哨兵切主，新主加载的 AOF 就缺这 1 秒之后的所有变更 - AOF 重写期间发生故障：
bgrewriteaof生成新 AOF 时若中断，可能留下破损文件；Redis 启动会拒绝加载并退回到 RDB，但如果 RDB 也过期，就表现为“回滚到更早状态” - 从节点被提升为主节点时，它的 AOF 可能尚未接收完主节点最后几条命令（尤其在网络延迟或主从复制积压大的场景）
RDB与AOF同时开启时，谁最终决定恢复内容？
答案明确：AOF 优先。只要 appendonly yes 且 appendonly.aof 文件存在且校验通过，Redis 启动时**完全忽略 dump.rdb**，哪怕后者时间更新。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
这意味着：
- 若 AOF 文件损坏，Redis 启动失败（报错
Bad file format reading the append only file），需手动用redis-check-aof --fix修复 - 若 AOF 文件完整但内容陈旧（比如从节点 AOF 滞后），则恢复的就是那个旧状态，看起来像“回滚”
- 若你希望强制用 RDB 恢复（例如确认 AOF 不可靠），必须先 rename 或删除
appendonly.aof，再启动 -
save触发的 RDB 快照时间点，和 AOF 最后一条命令的时间点，往往不同步——这是“数据不一致”的根源，不是 bug
生产环境最易忽略的三个配置细节
很多团队调好了哨兵，却栽在这几个不起眼的配置上：
-
stop-writes-on-bgsave-error yes：RDB 持久化失败时停止写入，避免数据只存在内存中；但若磁盘满导致 bgsave 失败，服务会静默只读，容易被误判为“正常” -
aof-load-truncated yes（Redis 4.0+）：当 AOF 文件末尾不完整（如突然断电），是否尝试加载前面有效部分；默认yes，但若设为no，会直接启动失败 -
dir和dbfilename/appendfilename路径不一致：RDB 写在/data，AOF 却写在/var/lib/redis，哨兵切主后新主可能根本找不到 AOF 文件，被迫加载旧 RDB
真正麻烦的从来不是“怎么配”，而是“配完有没有验证过故障路径”——比如 kill -9 主进程后观察从节点升主、再检查数据是否一致。没跑过这个流程，配置就是纸面逻辑。
