能加，但必须分三步走：先配好新节点、再用 redis-cli --cluster add-node 加入、最后手动或自动重分槽——跳过任何一步都可能让新节点“活着但没数据”。
能加，但必须分三步走：先配好新节点、再用 redis-cli --cluster add-node 加入、最后手动或自动重分槽——跳过任何一步都可能让新节点“活着但没数据”。
新节点配置必须满足集群通信前提
Redis 6.0 要求新节点启动前就具备集群识别能力，否则 add-node 会失败或加入后无法握手。常见错误是直接复用旧配置却漏改关键项：
-
cluster-enabled yes必须显式开启（不能靠注释掉） -
cluster-config-file必须指向**独立文件路径**，比如nodes-7006.conf；多个节点共用同一文件会导致启动冲突或节点 ID 混乱 -
bind不能只写127.0.0.1（除非所有节点都在本机），生产环境要填实际监听 IP，否则其他节点 ping 不通 - 如果集群启用了密码，
requirepass和masterauth必须一致，且值要和已有节点相同
redis-cli --cluster add-node 的参数陷阱
这个命令表面简单，但参数顺序和权限控制极易出错：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 命令格式固定为：
redis-cli --cluster add-node <new-node-addr><existing-node-addr></existing-node-addr></new-node-addr>，**不能颠倒顺序**，否则新节点会尝试把旧节点“拉进自己集群” - 如果集群有密码，
-a参数必须加在命令末尾，且要作用于existing-node-addr所在节点（即你连的那台），不是新节点本身 - 加从节点时，
--cluster-slave和--cluster-master-id必须同时出现；单独加--cluster-slave会让新节点随机选主，极可能选错 - 执行后不会立刻显示“成功”，而是输出一段节点列表快照 —— 关键要看新节点状态是否含
myself且 role 是master或slave，而不是noaddr或空行
加完节点不重分槽 = 新节点是“空壳”
刚加入的节点默认不持有任何 slot，CLUSTER NODES 里能看到它，但写入 key 会返回 MOVED 重定向到其他节点。必须做槽迁移才能真正扩容：
- 用
redis-cli --cluster reshard <any-existing-node></any-existing-node>启动交互式重分片，输入槽数量、目标节点 ID、源节点（可选all）、确认yes - 如果不想交互，可用
--cluster-from/--cluster-to/--cluster-slots组合实现脚本化迁移，但需确保源节点有足够空闲槽 - 迁移过程中，客户端可能收到
TRYAGAIN或短暂MOVED，属正常现象；但若持续报NOADDR，说明新节点网络不通或配置未生效 - 迁移完成前别重启新节点，否则
nodes-xxx.conf可能丢失部分迁移状态，导致槽归属混乱
最易被忽略的是：添加节点后，cluster-node-timeout 值会影响新节点被识别的速度，若设得过大（如 15000ms），在小规模集群中可能让 add-node 看似卡住——其实只是等超时判定，不是真卡死。
