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