ZooKeeper Leader宕机与脑裂处理
Leader故障和网络分区是最常见故障场景。
Leader宕机恢复
恢复流程:
Bash
1. Follower检测Leader心跳超时
2. 状态变LOOKING,发起选举
3. 过半节点投票选出新Leader
4. 新Leader同步数据
5. 集群恢复服务
时间节点:
| 阶段 | 时间 | 说明 |
|---|---|---|
| 心跳检测 | tickTime×syncLimit | 检测Leader宕机 |
| 选举阶段 | 数秒 | 过半投票 |
| 数据同步 | 取决差距 | DIFF/TRUNC/SNAP |
恢复验证命令:
Bash
# 检查Leader状态
echo stat | nc host1 2181 | grep Mode
# 输出: Mode: leader
# 检查ZXID一致性
echo srvr | nc host1 2181 | grep Zxid
echo srvr | nc host2 2181 | grep Zxid
恢复检查清单:
| 检查项 | 标准 |
|---|---|
| Leader状态 | 有且仅有一个Leader |
| ZXID一致 | 各节点ZXID相近 |
| 客户端连接 | 连接恢复正常 |
| 临时节点 | 需重新创建 |
临时节点恢复:
Bash
Leader宕机 → 会话可能失效
临时节点自动删除 → 客户端需重新创建
监听ConnectionState.LOST → 重建临时节点
恢复时间优化:
| 优化 | 说明 |
|---|---|
| 减小syncLimit | 加快故障检测 |
- 减小initLimit | 加快选举完成 | | 定期快照 | 减少同步数据量 |
注意:恢复时间取决于syncLimit和事务差距大小。
网络分区脑裂处理
脑裂场景:
text
网络分区导致集群分裂
两边的节点各自选举Leader
但只有过半一边能正常服务
过半保护机制:
| 分区情况 | 结果 |
|---|---|
| 少数派 | 无法选出Leader,停止服务 |
| 多数派 | 选出新Leader,继续服务 |
| 等分(如3节点分2+1) | 一边可服务,一边停止 |
脑裂检测:
text
# 检查各节点角色
echo stat | nc host1 2181 | grep Mode
echo stat | nc host2 2181 | grep Mode
echo stat | nc host3 2181 | grep Mode
# 如果出现两个Leader,说明脑裂
恢复步骤:
text
1. 修复网络分区
2. 确认合法Leader(ZXID更大)
3. 重启少数派节点
4. 节点自动加入正确集群
5. 验证集群状态
合法Leader判断:
text
对比ZXID大小:
ZXID更大 → 数据更完整 → 合法Leader
ZXID更小 → 数据落后 → 不合法
合法Leader保留,不合法Leader停止
预防措施:
| 措施 | 说明 |
|---|---|
| 奇数节点 | 避免等分 |
| 多机架部署 | 防单机架故障 |
| 网络监控 | 及时发现分区 |
脑裂恢复脚本:
text
#!/bin/bash
# 找出合法Leader
leader_zxid=0
leader_host=""
for host in $HOSTS; do
zxid=$(echo srvr | nc $host 2181 | grep Zxid | awk '{print $3}')
if [ $zxid > $leader_zxid ]; then
leader_zxid=$zxid
leader_host=$host
fi
done
echo "Legal Leader: $leader_host"
提示:过半机制天然防止脑裂数据不一致。
要点总结
- Leader宕机恢复:检测→选举→同步→恢复
- 恢复时间取决于syncLimit和数据差距
- 过半机制防止脑裂数据不一致
- 少数派无法选出Leader,自动停止
- ZXID更大者为合法Leader
- 预防脑裂:奇数节点、多机架部署
- 网络分区后重启少数派节点恢复
📝 发现内容有误?点击此处直接编辑