哨兵未将旧主降级为从库，通常因旧主未向新主发送__sentinel__:hello心跳导致哨兵无法识别其存活；或旧主配置错误（如bind、requirepass、protected-mode）、网络不通、quorum不足、slave-priority为0等阻碍slaveof执行。
哨兵没把旧主降级为从库，通常是因为它压根没连上新主
旧主节点恢复后，哨兵会尝试让它执行 SLAVEOF <new-master-ip><new-master-port></new-master-port></new-master-ip>，但前提是：旧主必须能被哨兵访问、且能连上新主。常见断链场景包括：
• 旧主配置了 bind 127.0.0.1，哨兵在另一台机器上，发不出命令
• 旧主启用了 requirepass，但哨兵的 sentinel auth-pass 没配或配错密码
• 新主节点防火墙未开放对应端口，旧主连不上它，SLAVEOF 命令直接超时失败
• 旧主的 protected-mode yes 且没配 bind 或 trusted-clients，拒绝来自哨兵的连接
SENTINEL slaves <master-name></master-name> 返回空列表，说明哨兵根本不知道旧主还活着
哨兵不是靠“定时扫 IP”发现旧主的，而是依赖旧主自己向新主的 __sentinel__:hello 频道发心跳。如果旧主恢复后：
• 没重启（或没重载配置），仍以主身份运行，就不会发 hello 消息
• 虽然重启了，但 sentinel monitor 配置里没包含它（比如只监控了新主），哨兵不会主动去连它
• 它连的是旧主地址（已失效），导致 INFO 回复里没上报正确角色和地址，哨兵无法识别其身份
验证方式：在旧主上执行 redis-cli INFO replication，确认 role 是 master；再在哨兵上执行 SENTINEL slaves mymaster，看返回是否含该节点
quorum 不足或选举卡住，导致故障转移流程没走完
即使旧主恢复了，如果哨兵集群本身还没完成上一轮故障转移（比如 leader 选举失败、新主未确认），它就不会进入“收编旧主”阶段。典型表现：
• 日志里有 +failover-abort-no-good-slave 或 +failover-end 缺失
• SENTINEL master mymaster 输出中 num-slaves 长期不变，failover-state 停在 SENTINEL_FAILOVER_STATE_WAIT_START 或 SENTINEL_FAILOVER_STATE_SELECT_SLAVE
• SENTINEL ckquorum mymaster 返回 OK，但 SENTINEL sentinels mymaster 只返回少于 quorum 数量的哨兵记录——说明部分哨兵物理失联，仲裁无法推进
旧主的 slave-priority 0 或 replica-announce-ip 配置错误
哨兵在让旧主降级时，会读取它的 INFO replication 输出来构造 SLAVEOF 命令。如果：
• 旧主设置了 slave-priority 0，哨兵会跳过它（认为“不接受降级”）
• 旧主的 replica-announce-ip 配错了（比如写成内网地址但哨兵在外网），哨兵拿到错误 IP 后发命令失败
• 旧主的 port 在 INFO 里显示为 0（常见于容器动态端口未显式暴露），哨兵无法构造有效连接
修复前先检查：在旧主上运行 redis-cli INFO replication | grep -E "(role|slave_priority|replica_announce)"
INFO 和 hello。
