结论：从节点未升主主因是资格被拒或投票失败；CLUSTER FAILOVER 必须在目标从节点本地执行，且需满足多数派、数据新鲜度、无配置冲突等条件。
直接说结论：从节点没升主，大概率不是“没触发”，而是“被拒之门外”——它压根没资格参选，或参选了但票没投给它。
CLUSTER FAILOVER 执行成功但角色没变
常见现象是命令返回 OK，但 CLUSTER NODES 里该节点仍显示 slave，甚至原主节点还活着。这说明你连错了节点——CLUSTER FAILOVER 必须在目标从节点本地执行，不能远程调用。Redis 不支持跨节点发起晋升请求。
- 确认当前连接的是目标从节点：
INFO replication输出中role:slave且master_host指向预期主节点 - 检查主节点是否真在线：
CLUSTER NODES中对应 master ID 的那一行，不能带fail?或fail标记 - 若主节点已失联，
CLUSTER FAILOVER会直接报错ERR Master is down or failed，此时必须改用CLUSTER FAILOVER FORCE（Redis 5.0+）或CLUSTER FAILOVER TAKEOVER
自动故障转移卡在 PFAIL 阶段不升级 FAIL
集群知道主挂了，但从节点迟迟不启动选举，根本原因是“多数派投票机制”没凑够票数——不是节点不够，而是在线的主节点数量不足。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 计算所需最小主节点数：
N/2 + 1，其中N是当前在线主节点总数；例如 3 主集群挂掉 2 个，只剩 1 个主在线 → 无法达成多数，永远停在PFAIL -
cluster-node-timeout设得太小（如低于 8000ms）会导致网络抖动被误判为宕机，频繁触发 PFAIL，但因多数派未形成，不会进入 FAIL 和选举 - 该参数不可热更新，修改后必须重启节点；生产环境建议设为
10000左右，并结合实际INFO replication中的lag值校准
从节点有资格参选但最终没当选
即使主节点已被标记为 FAIL，从节点也可能落选。关键看两个硬指标：数据新鲜度和投票时机。
- 复制偏移量落后太多会被直接淘汰：
slave-repl-offset与集群已知最大偏移量差值 >cluster-slave-validity-factor × cluster-node-timeout（默认 150 秒数据），就放弃参选 - 多个从节点几乎同时发起选举时，每个主节点只投第一张收到的
FAILOVER_AUTH_REQUEST；后到的请求直接被忽略，不排队不重试 - 休眠时间策略影响“抢票”顺序：休眠 =
500ms + [0–500ms] 随机 + (max_offset - self_offset) × 1000ms；offset 越大，休眠越短，越容易先发请求
配置冲突导致故障转移被静默拦截
最隐蔽的问题：你启用了 cluster-enabled yes，却在同一套实例上配了 Sentinel。两者逻辑互斥，Sentinel 会强行执行 SLAVEOF NO ONE 破坏集群拓扑，而 Cluster 层面可能还在等投票。
- 查
INFO replication：如果同时出现role:master和cluster_enabled:1，说明混合部署已生效，必须立刻清理 - 用
redis-cli --cluster check扫描，会明确报出类似node xxx is marked as fail but role=master的不一致 - Sentinel 的
sentinel monitor配置项若指向集群节点，它会无视集群角色，按传统主从方式尝试接管——这是架构级误配，不是参数调优能解决的
真正难处理的从来不是“怎么升”，而是“为什么不让升”：偏移量、投票数、配置纪元、混合部署……这些点都藏在日志和 CLUSTER NODES 输出的细节里，不逐行比对，光看表面状态很容易误判。
