根本原因是哨兵不负责“老主复活”的收编，原主重启后必须自行配置replicaof指向新主、配对masterauth、保持slave-read-only yes，才能被纳入复制拓扑。
Redis主节点重启后哨兵没把它拉回当从节点，根本原因不是哨兵“忘了”，而是它压根没收到指令去这么做——哨兵只负责故障转移时的升主和通知，不负责“善后收编”。原主节点重启后，得靠自己主动连新主、执行replicaof，哨兵不会替你发这条命令。
哨兵根本不处理“老主复活”这个动作
哨兵的职责边界很明确：监控、主观/客观下线判断、选举新主、通知从节点改配置、通知客户端。它不维护“谁曾经是主”这种历史状态，也不在后台轮询已下线节点是否复活。原主节点重启后，如果配置里还写着replicaof no one或没配replicaof，它就继续以独立主节点运行，和哨兵毫无关系。
- 哨兵日志里不会出现“re-add old master as slave”这类记录
-
sentinel slaves mymaster输出中也不会包含原主节点，除非它自己连上来并完成握手 - 即使你手动执行
redis-cli -p 6379 replicaof 127.0.0.1 6380，哨兵也只会在下次INFO replication轮询时被动发现，不会主动干预
原主节点重启后必须满足三个条件才能被自动接纳为从节点
它不是“恢复”，而是“重新加入复制拓扑”，这需要它自己完成初始化连接，且哨兵和新主都认可其身份：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 配置文件中必须有正确的
replicaof指向当前主节点（不能写死旧IP，尤其发生过切换后） - 若新主启用了
requirepass，原主必须配置匹配的masterauth，否则同步直接失败，日志里只有NOAUTH Authentication required - 原主的
slave-read-only yes需保持开启，否则哨兵可能拒绝将其纳入健康从节点列表（尤其当sentinel down-after-milliseconds较小时，写入行为会触发误判）
最容易被忽略的验证点：INFO replication 输出里的 role 和 master_host
别只看哨兵是否“认出”它，重点看它自己是否真的进入了复制状态：
- 在原主节点上执行
redis-cli info replication，必须看到role:slave且master_host指向当前新主地址（不是127.0.0.1或空） -
master_link_status:up和slave_repl_offset持续增长，才说明同步活了；如果一直是master_link_status:down，八成是masterauth没配对或网络不通 - 新主节点的
INFO replication中connected_slaves数量应+1，且对应slaveX行里ip字段是原主的真实IP，不是127.0.0.1
真正卡住的往往不是哨兵逻辑，而是原主节点重启后仍带着旧配置、旧密码、旧角色启动，然后安静地当一个没人理的孤岛主节点。它不会喊疼，哨兵也不会找它——得你自己去检查它的redis.conf和INFO replication输出。
