实验Redis Cluster时，故障后如何重启集群节点？

别担心，我来帮你梳理Redis Cluster节点故障后的重启步骤，结合你给出的集群状态信息（比如30005是slave节点，30003、30002是master节点），咱们分两种核心场景来说：

一、从节点故障重启（比如你的30005节点） #

从节点的重启流程很简单，因为它本身不持有集群的槽位（slot），恢复起来更直接：

• 直接用原配置文件启动故障节点：

  redis-server /path/to/redis-30005.conf
  

  这里要替换成你实际的配置文件路径，确保配置里cluster-enabled yes、cluster-config-file等集群相关参数和之前一致。
• 启动后，节点会自动重新加入集群，并且和对应的主节点（你这里是bd76f831d34ed265开头的master）同步数据，恢复slave角色。
• 验证：在任意集群节点上执行以下命令，检查该节点状态：

  redis-cli -p 30002 cluster nodes | grep 30005
  

  输出里应该显示slave、connected，没有fail标记。

二、主节点故障重启（比如你的30003、30002节点） #

主节点的情况要分两种子场景，取决于故障期间集群是否已经触发了故障转移：

子场景1：故障后未触发故障转移（集群还没选举新master） #

这种情况一般是节点短时间故障，集群的cluster-node-timeout还没到：

• 直接用原配置文件启动故障主节点：

  redis-server /path/to/redis-<故障端口>.conf
  

• 启动后，节点会重新加入集群，恢复原来的master角色，它持有的槽位（比如30003节点的10923-16383）会正常生效。
• 验证：执行redis-cli -p <任意集群端口> cluster nodes，看该节点状态为master、connected，槽位分配正常。

子场景2：故障后已触发故障转移（原slave升级为新master） #

如果节点故障时间超过cluster-node-timeout，集群会自动把对应的slave升级为新master，这时候原主节点重启后会自动变为新master的slave：

• 先启动原故障主节点：

  redis-server /path/to/redis-<原master端口>.conf
  

• 启动后，节点会自动识别集群内的新master，同步数据并成为其slave。
• （可选）如果你需要把原主节点恢复为master角色，可以在新master上手动触发故障转移：

  redis-cli -p <新master端口> cluster failover
  

  这一步非必需，集群的高可用已经正常运行，除非你有特定的拓扑需求。
• 验证：查看cluster nodes输出，确认原主节点的角色和关联关系正常。

几个关键注意事项 #

• 必须使用原来的配置文件启动，不能修改cluster-config-file、cluster-node-id（如果配置里有）等参数，否则节点会以全新ID加入集群，导致冲突。
• 如果节点启动后没有自动加入集群，可以在任意正常集群节点上手动执行：

  redis-cli -p <正常节点端口> cluster meet <故障节点IP> <故障节点端口>
  

• 如果节点磁盘数据损坏，启动后会自动从master同步全量数据，这个过程集群会自动处理，无需手动干预。

内容的提问来源于stack exchange，提问作者dotnetstep