config-epoch冲突源于多个哨兵为同一主节点生成不可合并的版本号，主因是quorum过低、网络抖动误判、旧纪元残留、RESET未同步或网络分区恢复后纪元不一致；避免需设合理quorum、清空模板配置、全量RESET并重启；修复须停全部哨兵、删config-epoch行、统一配置、按序启动并校验纪元一致。
哨兵配置纪元（config-epoch）冲突不是配置错误，而是多个哨兵对同一主节点生成了不同且不可合并的纪元值，会导致故障转移卡在“等待其他哨兵确认”状态，新主无法被承认。
为什么 config-epoch 会冲突？
config-epoch 是哨兵为每个主节点维护的单调递增整数，用于标识该主节点当前配置的“版本”。它由领头哨兵在故障转移开始时通过 SENTINEL FAILOVER 或自动选举生成，并广播给其他哨兵。冲突发生的核心场景有：
- 多个哨兵**同时发起故障转移**（例如 quorum 设置过低、down-after-milliseconds 过短、网络抖动导致误判 SDOWN）
- 旧哨兵进程残留：杀掉哨兵后未清空
sentinel.conf中已写入的sentinel config-epoch mymaster N行，重启后继续用旧纪元参与投票 - 手动执行
SENTINEL RESET mymaster后未同步所有哨兵：该命令只重置本机状态，不广播，其他哨兵仍保留旧纪元，下次投票就会拒绝新纪元 - 哨兵之间网络分区恢复后，各自在隔离期间生成了不同纪元，Gossip 无法自动收敛
如何避免 config-epoch 冲突？
关键不是“修复已冲突”，而是从部署和运维环节切断冲突源头：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- quorum 值必须设为 ≥ ⌈(哨兵总数 + 1) / 2⌉ —— 3 个哨兵就设
sentinel monitor mymaster 192.168.1.10 6379 2，5 个设 3；绝不能设为 1，否则任意哨兵都能单方面触发 failover - 确保所有哨兵启动前，
sentinel.conf中不含任何sentinel config-epoch行 —— 它是运行时写入的，模板里出现就是隐患 - 每次修改监控目标（如主节点 IP 变更），必须对所有哨兵执行
SENTINEL RESET *，然后逐个 reload 配置（redis-cli -p 26379 CONFIG REWRITE不生效，要用SENTINEL MONITOR或重启） - 禁止在生产环境手动执行
SENTINEL FAILOVER，除非你明确知道当前所有哨兵的 config-epoch 状态（可用redis-cli -p 26379 SENTINEL CKQUORUM mymaster和INFO sentinel交叉验证）
发现 config-epoch 冲突后怎么救？
现象是日志反复出现 Ignoring the CONFIG REPLICATION command from ... since I have a newer config-epoch 或 Refusing to accept new configuration for mymaster: I have a newer config-epoch，且 INFO sentinel 中 num-slaves 正常但 leader 字段为空：
- 先停掉所有哨兵进程（
kill -9或systemctl stop redis-sentinel） - 检查每个
sentinel.conf文件末尾，删除所有sentinel config-epoch mymaster N行 - 确认所有哨兵的
sentinel monitor行完全一致（包括名称、IP、端口、quorum） - 逐台启动哨兵，启动间隔至少 5 秒，让首个启动的哨兵先建立初始纪元，后续哨兵通过 Gossip 自动同步
- 启动后立即执行
redis-cli -p 26379 SENTINEL CKQUORUM mymaster，输出应为OK；再查INFO sentinel | grep "current-epoch"，所有哨兵数值必须相同
真正难处理的是“纪元已分裂但哨兵仍在运行”的状态——此时热修复极容易引发二次分裂。最稳妥的做法永远是停全量、清纪元、按序启，而不是尝试在线 patch。
