必须先升级从节点并确认完全同步（master_repl_offset与slave_repl_offset差值为0且master_link_status为up）再手动切换角色，否则直接停主节点会触发自动故障转移，导致槽位迁移、连接中断、写丢失及数据不一致。
直接停主节点升级会触发自动故障转移，导致槽位迁移、连接中断、写丢失——尤其在高负载下，从节点复制积压没追平就切主，replica_repl_offset落后会导致数据不一致。必须先升从节点、确认完全同步、再手动切换角色，才能保证每个分片始终有可用主节点在线。
怎么确认从节点已完全同步再升级
升级前不验证同步状态，是集群升级失败最常见原因。INFO replication 中的 master_repl_offset 和 slave_repl_offset 差值必须为 0，且 master_link_status 必须为 up。
- 执行
redis-cli -p 6380 INFO replication | grep -E "(master_repl_offset|slave_repl_offset|master_link_status)"，反复检查直到两个 offset 相等 - 如果差值非零，先查
repl_backlog_active:1是否为 1；若为 0，说明复制缓冲区已失效，需在原主节点增大repl-backlog-size（如设为 128mb）并等待追平 - 禁止在同步未完成时执行
CLUSTER FAILOVER或CLUSTER REPLICATE，否则元数据可能混乱
升级从节点二进制后为什么不能直接用 SLAVEOF NO ONE 切主
SLAVEOF NO ONE 不等于“安全接管”。它只是断开复制关系，但不会校验复制缓冲区是否有效、也不会通知集群其他节点——旧主仍认为自己是主，新节点未被分配 slot，客户端继续往旧主发请求就会报 MOVED 或 CLUSTERDOWN Hash slot not served。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 必须用
redis-cli -p 6380 cluster failover takeover（注意带takeover参数），这是集群模式下唯一能强制重分配 slot 的安全命令 - 切换后立刻运行
CLUSTER NODES，确认该节点 role 是master，且其负责的 slot 数量与原主一致 - 若旧主已下线但仍在节点列表中，要在新主上执行
CLUSTER FORGET <old-master-node-id></old-master-node-id>清除残留视图
客户端连接池为什么总连不上新主节点
不是服务没起来，而是客户端缓存了过期的 slots map。JedisCluster、Lettuce 等主流驱动不会自动感知集群拓扑变更，必须显式刷新。
- JedisCluster 需调用
jedisCluster.refreshClusterNodes()或触发内部 reset 逻辑（不能只靠超时） - Lettuce 要调用
redisClient.refreshClusterNodes()，且确保配置了DynamicNodeResolver - 所有节点必须开启
cluster-require-full-coverage no，否则任意一个 slot 不可达就会拒绝全部请求
真正容易被忽略的是：升级后不立即执行 CONFIG REWRITE，重启会回退为从节点；还有新版 Redis（7.0+）对 replicaof 和 ACL 认证更严格，若配置里还留着已废弃的 slaveof 或混用 masterauth 与 masteruser，进程可能静默启动失败或复制链路中断但无日志报错。
