CLUSTER REPLICATE 在 Redis Cluster 中不生效，因为集群模式下主从关系由 Gossip 协议自动管理，该命令被硬编码拦截并返回 ERR；正确做法是使用 redis-cli --cluster replicate 或先退出集群再以普通从节点方式配置。
Redis 集群中不能用 CLUSTER REPLICATE 手动指定从节点归属主节点——它只在非集群模式（即启用 cluster-enabled no 的普通主从）下有效。
为什么 CLUSTER REPLICATE 在 Redis Cluster 里不生效
Redis Cluster 自己管主从关系：节点加入集群后，通过 Gossip 协议自动协商角色，从节点必须通过 CLUSTER FAILOVER 或故障转移触发的自动重分配来绑定主节点。你发 CLUSTER REPLICATE <node-id> 给一个已加入集群的节点，它会直接返回 ERR This node is configured as a cluster node。
- 错误现象：
CLUSTER REPLICATE xxxxxx返回ERR This node is configured as a cluster node - 根本原因：Redis 在
cluster-enabled yes模式下禁用了该命令的写入逻辑，防止人工干预破坏集群一致性状态 - 混淆点：文档里没明确标“仅限单机主从”，但源码中
clusterCommand()对REPLICATE子命令做了硬拦截
想让某个节点当指定主节点的从节点，该怎么做
必须先让目标从节点退出集群，再以普通从节点身份连接主节点，最后重新加入集群——但注意：这会暂时破坏槽位分布，需人工补全。
- 步骤顺序不能错：
CLUSTER RESET HARD→ 关闭cluster-enabled→ 启动并SLAVEOF <master-ip> <master-port>→ 等同步完成 → 改回cluster-enabled yes→CLUSTER MEET重新加入 - 风险点：
CLUSTER RESET HARD会清空当前节点所有槽信息和集群配置纪元（config epoch），若误操作在主节点上执行，会导致整个集群无法识别它 - 替代方案更稳妥：用
redis-cli --cluster replicate <slave-node-id> <master-node-id>（底层调的是CLUSTER SETSLOT ... MIGRATING/IMPORTING+ 故障模拟），但要求两节点已在同一集群且主节点无正在迁移的槽
redis-cli --cluster replicate 实际干了什么
它不是发 CLUSTER REPLICATE，而是模拟一次手动故障转移前的准备动作：把目标从节点标记为指定主节点的“待选从节点”，等下次 CLUSTER FAILOVER 或主节点宕机时才会真正切换角色。
- 执行后不会立刻改变
CLUSTER NODES输出里的slave字段，仍显示master - 只有在主节点实际下线或主动触发
CLUSTER FAILOVER后，该从节点才被选举为新主，并在其他节点的CLUSTER NODES中更新为slave状态 - 参数必须是 40 位 hex node ID，不是 IP:PORT；ID 可从任意集群节点的
CLUSTER NODES输出里复制 - 常见失败：
No such node表示 ID 错或节点未握手成功；Node is not empty表示该节点已有槽分配（得先CLUSTER DELSLOTS清空）
真正难的不是命令怎么敲，而是搞清“谁在控制角色分配”——集群模式下是 Raft-like 投票机制+心跳检测，不是人能插手的。一旦发现 CLUSTER REPLICATE 返回 ERR，第一反应不该是换参数，而是确认自己是不是在跟集群模式较劲。
