脑裂问题 | 小菜鸟

Elasticsearch 脑裂问题：原理、成因与解决方案

在 Elasticsearch 集群中，脑裂（Split Brain） 是一种严重的集群异常状态，指集群中同时存在多个主节点（Master），导致数据分片分配、请求路由混乱，最终引发数据不一致。本文详细解析脑裂的成因、检测方法及根治方案。

什么是脑裂？

Elasticsearch 集群依赖单一主节点（Master）维护集群状态（如分片分配、节点信息）。正常情况下，主节点由候选主节点（Master Eligible Node）选举产生，且集群中始终只有一个主节点。

脑裂发生时：
由于网络分区或节点通信中断，集群被分割成多个独立子集群。每个子集群都认为原主节点已宕机，从而各自选举出新的主节点。此时，集群中出现多个主节点，各自维护一套集群状态，导致：

数据写入分散在不同子集群，无法同步。
搜索请求命中不同主节点时，返回结果不一致。
分片分配混乱，可能出现重复或丢失。

脑裂的常见成因

网络问题（最主要原因）

网络延迟 / 分区：集群节点间网络不稳定（如交换机故障、防火墙拦截），导致部分节点无法与主节点通信。
网络超时：节点间心跳检测（Ping）超时，误认为主节点宕机。

节点负载过高

若主节点同时承担数据存储和计算任务（即既是 Master 又是 Data Node），当流量激增时，主节点可能因 CPU / 内存耗尽而 “假死”（无法响应心跳）。
其他节点长时间未收到主节点响应，判定主节点宕机，触发新主节点选举。

配置不合理

discovery.zen.minimum_master_nodes 配置错误：该参数未设置为 “候选主节点数的半数 + 1”，导致小集群也能选举主节点。
超时时间过短：discovery.zen.ping.timeout 设置过小（默认 3s），网络轻微波动就会触发误判。

关键配置：从根源预防脑裂

Elasticsearch 通过以下核心配置预防脑裂，需根据集群规模合理设置。

1. `discovery.zen.minimum_master_nodes`（核心！）

作用：指定选举主节点时，至少需要多少个候选主节点同意，才能成功选举。
原理：确保选举出的主节点得到 “多数派” 支持，避免小集群分裂后单独选举主节点。
推荐值：(候选主节点数 / 2) + 1（向上取整）。
- 示例：3 个候选主节点 → 3/2 +1 = 2；5 个候选主节点 → 5/2 +1 = 3。

2. `discovery.zen.ping.timeout`

作用：节点间心跳检测的超时时间（默认 3s）。
优化建议：网络不稳定的集群可适当调大（如 5~10s），减少因短暂延迟导致的误判。

节点角色分离

将主节点与数据节点分离：
- 配置专门的 候选主节点（node.master: true，node.data: false），仅负责集群管理，不处理数据请求。
- 数据节点（node.master: false，node.data: true）专注于数据存储和查询，避免主节点负载过高。

配置示例（3 节点集群）

# 候选主节点配置（node-1, node-2, node-3）
node.name: node-1
node.master: true    # 允许作为候选主节点
node.data: false     # 不存储数据（纯主节点）
discovery.zen.minimum_master_nodes: 2  # 3个候选主节点 → 2
discovery.zen.ping.timeout: 6s         # 延长超时时间

# 数据节点配置（node-4, node-5）
node.name: node-4
node.master: false   # 不参与主节点选举
node.data: true      # 存储数据

Elasticsearch 7.x+ 版本的变化

Elasticsearch 7.0 及以上版本移除了 zen discovery 机制，改用 cluster.initial_master_nodes 配置初始化集群，同时保留了 “多数派选举” 的核心逻辑：

初始化主节点：首次启动集群时，通过以下配置指定初始候选主节点：
1
cluster.initial_master_nodes: ["node-1", "node-2", "node-3"] # 候选主节点列表
自动维护最小主节点数：7.x+ 会自动计算 minimum_master_nodes（即多数派），无需手动配置，但仍需保证候选主节点数 ≥3 以提高稳定性。

脑裂的检测与恢复

1. 如何检测脑裂？

查看主节点信息：在不同节点执行 GET _cluster/state/master_node，若返回不同的主节点 ID，则存在脑裂。
监控集群状态：通过 GET _cluster/health 查看是否有 “分裂” 迹象（如分片状态异常、节点数不一致）。
日志分析：检查节点日志（elasticsearch.log），若出现 “master left”“electing new master” 等频繁日志，可能是脑裂前兆。

2. 脑裂恢复步骤

停止所有节点：避免数据进一步混乱。
清理异常节点数据：删除问题节点的 data 目录（仅在确认数据可通过其他节点恢复时操作）。
重启集群：先启动候选主节点，确保 minimum_master_nodes 配置正确，待主节点选举完成后，再启动其他节点。
校验集群状态：通过 GET _cluster/health 确认集群状态为 green，主节点唯一。

最佳实践

候选主节点数：建议设置 3~5 个（奇数），避免 “平票” 导致选举失败。
网络稳定性：确保节点间网络低延迟（<100ms），使用独立交换机，避免跨机房部署（必要时用专线）。
监控告警：通过 Prometheus + Grafana 监控主节点数量、集群状态、节点通信延迟，设置脑裂告警（如主节点数 >1）。
定期演练：模拟网络中断场景，验证集群是否会触发脑裂，测试恢复流程。