把新节点加入集群
add-node 用于把新节点加入已有集群。第一步是先让新实例按集群模式启动：打开集群开关，使用独立的端口与节点配置文件。然后用 redis-cli --cluster add-node 把它加进去。以主节点身份加入时，它一开始不负责任何槽，必须再用 reshard 分配槽位才能真正分担流量；以从节点身份加入时要追加 --cluster-slave 与 --cluster-master-id 指定归属的主节点。
基本信息
| 加入主节点 | redis-cli --cluster add-node <新节点> <任一现有节点> |
|---|---|
| 加入从节点 | 追加 --cluster-slave --cluster-master-id <主节点id> |
| 前置条件 | 新实例已按集群模式启动，端口与配置文件独立 |
| 后续步骤 | 主节点必须用 reshard 分配槽位 |
| 复核 | 用 --cluster check 确认拓扑与槽覆盖 |
典型使用场景
- 容量不足时水平扩容，增加分片数量
- 为提升可用性给现有主节点补充从节点
- 机器换代：新机加入、迁走槽位、下线旧机器
- 机房调整后重排副本位置，让主从跨机房分布
- 演练扩容流程，验证脚本与文档是否仍然可用
扩容流程
扩容流程
redis-cli --cluster add-node 10.0.0.14:7000 10.0.0.11:7000
redis-cli --cluster add-node 10.0.0.15:7000 10.0.0.11:7000 --cluster-slave --cluster-master-id <主节点id>
redis-cli --cluster reshard 10.0.0.11:7000 # 为新主节点分配槽
redis-cli -p 7000 CLUSTER NODES | grep 10.0.0.14 # 确认新节点已出现
redis-cli --cluster check 10.0.0.11:7000 # 复核拓扑与槽覆盖扩容步骤
| 步骤 | 动作 | 目的 |
|---|---|---|
| 准备实例 | 按集群参数启动，端口与配置独立 | 避免与现有节点冲突 |
| add-node | 加入集群 | 新节点先以无槽状态存在 |
| reshard | 把部分槽迁过来 | 让新节点真正分担流量 |
| check | 复核拓扑与覆盖 | 确认结果符合预期 |
新加入的主节点如果不分槽，集群容量并没有变化，故障域却变大了。这属于无效扩容，而且很容易被忽略，因为节点数量看起来确实增加了。
从节点数量直接决定故障转移能力：给每个主节点至少配一个从节点，主节点失效时才有候补可以提升，否则该分片只能等人工介入。
扩容过程中的迁移会在源节点与目标节点上同时产生开销：搬运命令是同步阻塞操作，迁移的槽越多、键越大，业务侧的抖动越明显。把分配槽的动作安排在低峰执行，迁完再用体检命令确认槽覆盖完整，是相对稳妥的做法。