Redis原生主从复制不支持自动故障转移，从节点不会自动升主；必须启用哨兵或Cluster模式才能实现自动接管，且需严格配置密码、quorum、复制偏移量等参数确保切换成功。

主节点宕机后从节点不会自动接管，除非启用哨兵或集群

Redis 原生主从复制本身 不提供自动故障转移能力。从节点只会持续尝试重连原主节点，不会自行升格为新主节点。你看到的“从节点接管”现象，一定是背后启用了 redis-sentinel 或 Redis Cluster 模式。单纯靠 slaveof 或 replicaof 配置，replicaof no one 必须手动执行，否则永远只是只读从节点。

哨兵模式下自动接管失败的常见原因

即使部署了哨兵，接管失败也高频发生，核心问题往往不在哨兵配置本身，而在主从节点的密码认证协同上：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• requirepass 和 masterauth 必须同时设置且值一致——主节点设了密码但从节点没配 masterauth，会导致从节点无法在故障转移后与新主（原从）建立复制连接，哨兵日志里会出现 NOAUTH Authentication required 或 Failed to AUTH
• 哨兵配置中 sentinel monitor 的 quorum 值必须 ≤ 实际运行的哨兵节点数的一半向下取整（例如 3 个哨兵，quorum 至少为 2），否则无法达成“客观下线”共识
• 主节点宕机后，若剩余从节点中存在 slave-read-only no 或人为执行过 replicaof no one，该节点可能被哨兵误判为不可用或状态混乱，跳过选举
• sentinel down-after-milliseconds 设置过大（如超 30s），会导致故障发现延迟，业务感知明显

验证接管是否真生效的三个关键检查点

别只看哨兵日志说“+switch-master”，要确认实际服务已切换成功：

• 查新主节点的 INFO replication：输出中 role:master 且 connected_slaves ≥ 1，master_replid 应为新 ID（非原主的 replid）
• 查从节点的 INFO replication：master_host 和 master_port 必须指向新主地址，而非原主或 localhost
• 客户端直连新主执行 SET 再从任一从节点 GET，确认写入能同步——很多情况下哨兵切换了，但应用仍连着旧主地址或 DNS 缓存未刷新，导致写入失败

集群模式下主节点宕机的接管逻辑完全不同

Redis Cluster 不依赖哨兵，而是靠节点间 Gossip 协议和投票机制完成故障转移。但它的前提更严格：

• 每个主节点必须至少有 1 个从节点，且集群总节点数 ≥ 6（3 主 3 从是最低可用拓扑）
• 从节点必须与主节点保持 cluster-node-timeout 内的心跳（默认 15s），超时即开始发起 CLUSTER FAILOVER 投票
• 从节点需满足两个硬性条件才能被选为新主：slave-replica-offset 接近主节点（落后不能超过 cluster-slave-validity-factor × node-timeout），且自身 cluster-require-full-coverage 为 yes（否则整个集群会拒绝写入）
• 集群模式下 requirepass 只需全局配置，无需单独设 masterauth——因为节点间通信走的是内部 cluster bus，不走 client port 认证

哨兵或集群的自动接管都不是开箱即用的黑盒，密码错配、quorum 算错、offset 落后太多、DNS 缓存残留……任何一个环节卡住，都会让“自动”变成“看起来自动实则挂起”。真正上线前，务必用 KILL -9 杀主进程 + 客户端轮询验证的方式，跑通一次完整故障闭环。