Redis集群节点故障与恢复详解
🔄 主节点宕机后恢复的完整过程
1. 主节点宕机检测
bash
# 集群检测到主节点不可用
>>> Node 127.0.0.1:7001 is unreachable
>>> Cluster state changed: fail2. 自动故障转移
bash
# 从节点自动升级为主节点
>>> Failover election won: promoting slave 127.0.0.1:7004 to master
>>> Configuring 127.0.0.1:7004 as master for slots 0-54603. 原主节点重新上线
bash
# 宕机的主节点重新启动
redis-server /path/to/redis.conf
# 节点自动重新加入集群
>>> Node 127.0.0.1:7001 rejoined the cluster4. 角色转换过程
bash
# 重新加入后，原主节点变为新主节点的从节点
127.0.0.1:7001> cluster nodes
# 输出显示：
# 127.0.0.1:7004 master - 负责槽位 0-5460
# 127.0.0.1:7001 slave 127.0.0.1:7004 - 变为从节点5. 数据同步
bash
# 新从节点开始同步数据
>>> 127.0.0.1:7001 starting replication from 127.0.0.1:7004
>>> SYNC with master, discarding 150 bytes of pre-sync data
>>> MASTER <-> REPLICA sync: receiving 2048 bytes from master⚠️ 其他可能的故障场景
场景1：多个主节点同时宕机
bash
# 情况：2个主节点同时故障
>>> 127.0.0.1:7001 and 127.0.0.1:7002 are unreachable
# 影响：
# - 如果超过半数主节点宕机，集群将不可用
# - 客户端收到 CLUSTERDOWN 错误
# - 需要人工干预恢复场景2：主节点和其从节点同时宕机
bash
# 情况：主节点7001和其从节点7004同时故障
>>> No available slaves for master 127.0.0.1:7001
# 影响：
# - 该主节点负责的槽位数据不可访问
# - 集群部分功能受损
# - 需要从备份恢复或等待节点重启场景3：网络分区（脑裂）
bash
# 情况：集群被网络分割成两个部分
Part A: 7001(master), 7004(slave), 7002(master)
Part B: 7003(master), 7005(slave), 7006(slave)
# 可能发生：
# - 两个分区都认为自己是有效集群
# - 数据写入冲突
# - 网络恢复后需要解决数据一致性场景4：从节点宕机
bash
# 情况：从节点7004宕机
>>> Slave 127.0.0.1:7004 is unreachable
# 影响：
# - 主节点7001失去备份
# - 集群仍然可用，但冗余性降低
# - 自动重连后重新同步数据场景5：节点数据不一致
bash
# 情况：节点重启后数据版本冲突
>>> Node 127.0.0.1:7001 has inconsistent config epoch
>>> Cluster state changed: fail
# 解决：需要手动修复
redis-cli --cluster fix 127.0.0.1:7001🛠️ 故障恢复命令
检查集群状态
bash
# 查看集群健康状态
redis-cli --cluster check 127.0.0.1:7001
# 查看节点信息
redis-cli -c -p 7001 cluster nodes
# 查看集群信息
redis-cli -c -p 7001 cluster info手动故障转移
bash
# 在从节点上执行手动故障转移
redis-cli -p 7004 cluster failover
# 强制故障转移（即使主节点可用）
redis-cli -p 7004 cluster failover force修复集群状态
bash
# 修复集群配置
redis-cli --cluster fix 127.0.0.1:7001
# 重新分片恢复
redis-cli --cluster reshard 127.0.0.1:7001📊 故障影响分析表
| 故障场景 | 集群状态 | 数据可用性 | 自动恢复 | 需要人工干预 |
|---|---|---|---|---|
| 单主节点宕机 | 部分降级 | 部分影响 | ✅ 是 | ❌ 否 |
| 多主节点宕机 | 可能不可用 | 严重影响 | ❌ 否 | ✅ 是 |
| 主从同时宕机 | 部分不可用 | 数据丢失 | ❌ 否 | ✅ 是 |
| 网络分区 | 分裂 | 不一致 | ⚠️ 部分 | ✅ 是 |
| 从节点宕机 | 正常 | 完全可用 | ✅ 是 | ❌ 否 |
🔧 预防措施
配置优化
bash
# 合理设置超时时间
cluster-node-timeout 15000
# 启用持久化
appendonly yes
appendfsync everysec
# 监控配置
# 设置适当的副本数
--cluster-replicas 1监控告警
bash
# 定期检查集群状态
redis-cli --cluster check 127.0.0.1:7001
# 监控关键指标
- 节点连接状态
- 内存使用情况
- 复制延迟
- 集群状态💡 最佳实践建议
- 至少配置1个从节点确保高可用
- 定期备份集群数据
- 监控集群健康状态
- 测试故障恢复流程
- 使用支持集群的客户端
通过理解这些故障场景和恢复机制，可以更好地设计和维护Redis集群，确保业务的连续性和数据的安全性。