Redis哨兵集群节点故障与恢复详解 - 以1主2从3哨兵为例

集群架构概述

在1主2从3哨兵的架构中：

• 1个主节点：处理所有写操作和读操作
• 2个从节点：复制主节点数据，处理读操作
• 3个哨兵节点：监控Redis实例，实现自动故障转移

哨兵节点故障与恢复

1. 单个哨兵节点故障

故障影响：

• 集群仍能正常工作
• 剩余2个哨兵仍能达成共识（满足多数原则）
• 故障检测和故障转移能力不受影响

恢复过程：

# 1. 重启故障哨兵节点
redis-sentinel /path/to/sentinel.conf

# 2. 或者直接启动
redis-server /path/to/sentinel.conf --sentinel

哨兵恢复后的行为：

• 自动重新加入哨兵集群
• 从其他哨兵获取最新拓扑信息
• 开始参与监控和投票

2. 多个哨兵节点故障

场景分析：

• 2个哨兵故障：剩余1个哨兵无法达成多数，故障转移无法进行
• 3个哨兵全故障：监控完全失效，但Redis数据服务仍正常运行

恢复步骤：

# 逐个恢复哨兵节点
# 第一个恢复的哨兵会尝试选举自己为leader，但需要多数同意
redis-sentinel /path/to/sentinel.conf

# 等待多数哨兵恢复后，集群恢复正常监控能力

数据节点故障与恢复

1. 从节点故障

故障检测：

# 哨兵日志示例
+sdown slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379

恢复过程：

# 自动恢复
1. 从节点重启成功
2. 哨兵检测到节点恢复：-sdown slave 127.0.0.1:6380
3. 从节点重新同步主节点数据
4. 恢复完成：+reboot slave 127.0.0.1:6380

手动干预（如果需要）：

# 检查从节点状态
redis-cli -p 6380 info replication

# 如果同步有问题，重新配置主从
redis-cli -p 6380 SLAVEOF 127.0.0.1 6379

2. 主节点故障 - 故障转移全过程

阶段一：故障检测

# 哨兵日志序列
+sdown master mymaster 127.0.0.1 6379
+odown master mymaster 127.0.0.1 6379 #quorum 3/2
+new-epoch 1
+try-failover master mymaster 127.0.0.1 6379

阶段二：领导者选举

• 哨兵节点通过Raft算法选举领导者
• 需要多数哨兵同意（3个哨兵需要至少2票）

阶段三：故障转移执行

# 选择新的主节点（基于优先级、复制偏移量等）
+vote-for-leader sentinel1 1
+selected-slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379

# 提升从节点为主节点
+failover-state-send-slaveof-noone slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379

# 重新配置其他从节点
+failover-state-reconf-slaves master mymaster 127.0.0.1 6379
+slave-reconf-sent slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379

# 故障转移完成
+failover-end master mymaster 127.0.0.1 6379
+switch-master mymaster 127.0.0.1 6379 127.0.0.1 6380

3. 原主节点恢复

恢复后的状态：

• 原主节点重启后自动成为新主节点的从节点
• 自动开始数据同步

哨兵日志：

# 原主节点恢复检测
-sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6380

# 重新配置为从节点
+convert-to-slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6380

配置说明

关键哨兵配置参数

sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1

参数说明：

• quorum=2：至少需要2个哨兵同意才能标记主节点故障
• down-after-milliseconds=30000：30秒无响应认为节点下线
• failover-timeout=180000：故障转移超时时间3分钟

监控和诊断命令

哨兵状态检查

# 查看哨兵主节点信息
redis-cli -p 26379 sentinel master mymaster

# 查看哨兵从节点信息
redis-cli -p 26379 sentinel slaves mymaster

# 查看哨兵节点信息
redis-cli -p 26379 sentinel sentinels mymaster

# 获取当前主节点地址
redis-cli -p 26379 sentinel get-master-addr-by-name mymaster

节点状态验证

# 检查所有节点角色
redis-cli -p 6379 info replication
redis-cli -p 6380 info replication  
redis-cli -p 6381 info replication

最佳实践建议

1. 哨兵部署：

   • 哨兵节点分散在不同物理机器
   • 避免哨兵与Redis实例同时故障

2. 网络配置：

   • 确保节点间网络连通性
   • 合理设置超时参数

3. 监控告警：

   • 监控哨兵日志和状态
   • 设置故障转移告警

4. 恢复测试：

   • 定期进行故障转移演练
   • 验证数据一致性

这种架构能够提供高可用性，在单点故障时自动恢复，确保Redis服务的持续可用。