SLAVEOF NO ONE 是断连+角色重置的原子操作：终止复制连接、清空主节点状态、将 role 改为 master，运行时生效但重启回退，不清理数据、不通知其他节点。
SLAVEOF NO ONE 到底在改什么
它不是“升级”命令，而是“断连+角色重置”两个动作的原子操作。执行后，Redis 立即终止与原主节点的复制连接，清空 master_host、master_port 和 repl_offset 等内部状态，并将自身 role 从 slave 改为 master。此时它不再拉取任何数据，也不再向原主汇报心跳——它已彻底“单干”。
- 不修改配置文件：仅运行时生效，重启后若
redis.conf中仍保留slaveof行，会自动回退为从节点 - 不触发数据清理：所有已同步的数据全保留，新写入也直接落盘，和原主节点完全无关
- 不通知其他节点：其他从节点不会自动感知，客户端也不会自动重连——它只作用于当前这一个实例
哨兵为什么必须自己发 SLAVEOF NO ONE，而不是让运维手动敲
因为人工执行无法满足故障转移的三个硬性条件：共识判断、串行控制、状态闭环。哨兵集群（至少 3 个）需先通过多数派投票确认主节点“客观下线”，再选举 leader，由该 leader 精确选择一个健康从节点（基于 offset、runid、优先级等），然后原子化下发 SLAVEOF NO ONE，紧接着批量执行其他从节点的 SLAVEOF 新主IP 新主端口，最后更新自身 sentinel known-slave 映射并推送新主地址给客户端。
- 手动执行跳过投票环节，可能在脑裂场景中把网络分区里“假活”的从节点提为新主
- 手动执行无法保证其他从节点同步切换，容易出现多个主节点共存、数据分裂
- 手动执行后哨兵仍认为旧主在线，会持续尝试重连甚至触发误告警或自动回切
执行后 INFO replication 输出变化说明什么
对比执行前后的 INFO replication 输出，是验证是否真正完成角色切换最直接的方式：
- 执行前：
role:slave，含master_host、master_port、master_link_status:up等字段 - 执行后：
role:master，connected_slaves:0（除非已有其他从节点连上来），且master_host字段消失 - 注意：
master_link_status不再出现，repl_backlog_active变为 1（开启复制积压缓冲区），这是新主节点开始服务写请求的标志
最容易被忽略的持久化陷阱
执行 SLAVEOF NO ONE 后，节点虽已成为主节点，但如果没同步更新配置文件，一次意外重启就会让它变回从节点——而这时原主可能早已恢复，导致整个集群写入中断或数据覆盖。
- 必须手动编辑
redis.conf，删掉或注释掉slaveof行，否则CONFIG REWRITE或重启都会失效 - 如果使用 AOF 持久化，确保
appendonly yes已开启，否则新主节点写入的数据在宕机后会丢失 - 若原主节点后来修复并试图以从节点身份加入，必须显式执行
SLAVEOF 新主IP 新主端口，不能依赖旧配置——因为旧配置指向的是已下线的“幽灵主节点”
真正的难点不在命令本身，而在状态一致性：配置、内存、磁盘、哨兵元数据、客户端路由，五个地方必须全部对齐，缺一不可。
