redis cluster模式下不可用slaveof no one，必须用cluster replicate诱导故障转移；传统主从（cluster_enabled:0）才可安全执行slaveof no one，并需立即config rewrite持久化配置。
不能直接在 Redis Cluster 模式下用 SLAVEOF NO ONE 切换主从角色——这会破坏集群结构，导致节点失联、槽位丢失甚至数据不可用。
确认当前是 Cluster 模式还是传统主从
先连上目标节点执行：redis-cli -h 192.168.1.12 -p 7003 INFO server，检查输出中 cluster_enabled:1 是否为 1。
若为 1，说明启用的是 Redis Cluster；若为 0，则是传统主从（replicaof 配置），可走 SLAVEOF NO ONE 路径。
生产环境误判模式是切换失败的首要原因——Cluster 模式下所有节点都必须保持 cluster-enabled yes，且角色变更必须通过集群协议协调。
Cluster 模式下只能用 cluster replicate 诱导故障转移
cluster replicate 不是“提升为 master”，而是让一个 slave 节点改换复制源。真正触发角色变更，依赖集群检测到原 master 失联 + 多数节点投票通过 failover。
操作前必须验证：
- 目标从节点的
master_link_status是up，且connected_slaves> 0（说明它已同步完成） - 原 master 节点状态不是
fail（否则集群可能已在自动切换，人工干预反而冲突） - 执行命令时连接的是目标从节点本身，不是原 master 或其他节点
- 传入的
<new_master_id></new_master_id>必须来自cluster nodes输出中的 40 位节点 ID，不能是 IP 或端口
示例流程：
查节点列表：redis-cli -h 192.168.1.12 -p 7003 cluster nodes | grep slave
找到目标从节点行，提取其 master 字段对应的 ID（如 abcd1234...89ef）
再连该从节点执行：redis-cli -h 192.168.1.12 -p 7003 cluster replicate abcd1234...89ef
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
非 Cluster 模式下才可用 SLAVEOF NO ONE
仅当 cluster_enabled:0 且配置中无 cluster-announce-ip 等 Cluster 相关项时，才能安全执行：redis-cli -h 192.168.1.12 -p 6379 SLAVEOF NO ONE
执行后立刻生效：INFO replication 中 role 变为 master，connected_slaves 降为 0（除非其他节点主动连上来）。
但要注意：
- 原 master 不会自动降级，需人工执行
SLAVEOF <new_master_ip><new_master_port></new_master_port></new_master_ip> - 若原 master 有密码，新 master 必须提前配置
masterauth，否则从节点连不上 - 配置文件中
replicaof行必须注释掉，否则重启后又变回 slave - Redis 7.0 默认使用
replicaof而非slaveof，命令行仍兼容，但配置文件写法要一致
切换后必须验证槽位与客户端路由
Cluster 模式下，即使角色切换成功，客户端仍可能因缓存旧的 slot 映射而写错节点。
务必做两件事：
- 用
redis-cli -h 192.168.1.12 -p 7003 cluster slots确认目标节点已接管对应槽位范围 - 强制客户端刷新拓扑（如 Jedis 需调用
close()+ 重建连接；Lettuce 需触发reloadPartitions()） - 检查
cluster nodes输出中该节点 role 是否变为master，且无fail标记
最容易被忽略的是客户端侧：很多应用不会自动重载集群拓扑，切完后看似正常，实际请求仍在打向已下线的旧 master，导致超时或写入丢失。
