Redis节点分批重启操作教程

Redis集群分批次重启绝非简单逐个启动节点，而是一套严谨的动态收敛过程：必须严格遵循“停从节点优先、单节点操作、强制RDB落盘、逐级等待验证”的原则，尤其以`redis-cli --cluster check`返回OK为唯一可信的完成信号——它真实模拟集群仲裁逻辑，能穿透ping通但状态异常、nodes.conf残留旧标记、槽位分配冲突等所有“假绿灯”陷阱；跳过这一步，哪怕只漏掉一个节点的校验，都可能在后续节点重启时引发脑裂、槽位丢失或连接雪崩，让精心设计的分批操作功亏一篑。

怎么避免集群重启时“全挂掉”

Redis集群不是单机，6个节点一起硬重启，大概率触发脑裂、槽位丢失、客户端连接雪崩。真正安全的做法是：每次只动1个节点，等它完全回归集群（cluster_state=ok且cluster_known_nodes数稳定），再动下一个。

关键不是“快”，而是让redis-cli --cluster check能持续返回OK，而不是CLUSTERDOWN或FAIL状态。

• 别用kill -9直接干掉所有进程——这会跳过持久化和握手流程，节点重启后可能被其他节点标记为fail
• 别在高峰期执行——哪怕你分批操作，每轮重启仍会造成局部槽位不可用（通常几秒），客户端若没做重试/重定向兜底，会直接报错MOVED或ASK
• 别跳过cluster-node-timeout检查——默认15秒，如果你的网络延迟高或磁盘慢，这个值太小会导致节点刚起来就被误判下线

分批重启的实操节奏怎么卡

不是按顺序编号重启（比如7001→7002→7003），而是优先处理从节点（replica），最后动主节点（master）。因为从节点宕机不影响写入，但主节点宕机等于整个分片不可写。

每轮操作严格遵循：停 → 等确认退出 → 启 → 等ping通 → 等cluster nodes显示connected且角色正确 → 等--cluster check通过 → 再进下一轮。

• 停节点：redis-cli -p 7002 shutdown save（强制RDB落盘，不丢数据）
• 确认退出：! pgrep -f "redis-server.*7002" 或 redis-cli -p 7002 ping 返回Could not connect
• 启节点：redis-server /opt/redis/cluster/7002/redis.conf（确保配置里cluster-enabled yes且cluster-config-file路径可写）
• 等就绪：while ! redis-cli -p 7002 cluster info 2>/dev/null | grep -q "cluster_state:ok"; do sleep 1; done

为什么--cluster check比ping更关键

ping只说明进程活着、端口通了；cluster info只说明本节点认为自己状态正常；而redis-cli --cluster check 127.0.0.1:7001是模拟集群仲裁逻辑，会遍历所有节点连通性、槽位分配一致性、主从关系是否匹配——这才是真正的“绿灯”。

常见假绿灯场景：

• 节点起来了，但nodes.conf里还存着旧的fail标记，导致它拒绝加入集群——删掉该节点下的nodes.conf再重启
• 某从节点启动后一直卡在noaddr状态——检查它的cluster-announce-ip是否配置成容器内网IP而非宿主机IP
• --cluster check报Slot 1234 is assigned to 2 nodes——说明有节点加载了过期的nodes.conf，必须统一清空所有节点的nodes.conf再逐个拉起

批量脚本里最容易漏掉的等待逻辑

写for循环重启多个端口很轻松，但几乎没人真写对“等待集群收敛”的逻辑。下面这段才是生产可用的最小等待块：

redis-cli -p $port shutdown save
while pgrep -f "redis-server.*$port" >/dev/null; do sleep 0.5; done
redis-server /opt/redis/cluster/$port/redis.conf
# 等到本节点 ready
while ! redis-cli -p $port ping 2>/dev/null | grep -q "PONG"; do sleep 0.5; done
# 等到集群全局 ok
while ! redis-cli --cluster check 127.0.0.1:$port 2>&1 | grep -q "OK"; do sleep 1; done

注意：最后一行不能只检查本节点cluster info，必须调--cluster check，否则你会在第3个节点重启完时才发现第1个节点其实在后台悄悄退群了。

大规模集群重启最麻烦的从来不是命令敲不对，而是把“集群已恢复”这件事，当成一个可以靠时间估算的静态状态——它其实是动态协商结果，必须用集群自己的校验逻辑来确认。

好了，本文到此结束，带大家了解了《Redis节点分批重启操作教程》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多数据库知识！