中困难

ES集群管理与选主#

一句话答案#

ES 7.x+ 使用基于 Raft 的选主机制替代旧版 Zen Discovery，Master 节点负责集群元数据和分片分配决策，建议 3 个专用 Master 节点避免脑裂；集群健康通过 green/yellow/red 三色状态监控。

核心要点

集群健康状态#

状态	含义	处理
Green	所有 Primary + Replica 都正常分配	正常
Yellow	所有 Primary 正常，部分 Replica 未分配	扩节点
Red	部分 Primary 未分配（数据缺失）	紧急恢复

GET /_cluster/health
# {"status":"yellow","number_of_nodes":3,"unassigned_shards":2}

bash

选主机制（ES 7.x+）#

ES 7.x 引入新的选主协议（基于 Raft 简化版）：

1. 每个 Master-eligible 节点参与投票
2. 候选节点发起选举，需获得多数票（quorum = N/2 + 1）
3. 当选 Master 负责：
   - 管理集群状态（ClusterState）
   - 分片分配决策（哪个分片在哪个节点）
   - 索引创建/删除
   - 节点加入/离开处理

旧版 Zen Discovery 的问题：
- minimum_master_nodes 需手动配置
- 配置错误容易脑裂

新版改进：
- 自动发现 + 投票配置（initial_master_nodes 仅首次启动）
- 内置防脑裂，无需手动设置 quorum

plaintext

脑裂防护#

场景：3 Master 节点网络分区 → [M1] vs [M2, M3]

旧版风险：两边各选出一个 Master → 脑裂
新版机制：
  - [M1] 只有 1 票（不足 quorum=2）→ 无法当选
  - [M2, M3] 有 2 票 → M2 或 M3 当选
  - 分区恢复后 M1 加入多数派的集群

防脑裂最佳实践：
  - 使用奇数个 Master 节点（3 或 5）
  - 专用 Master 节点（不承担数据）

plaintext

节点发现与加入#

# elasticsearch.yml
cluster.name: my-cluster
node.name: node-1
node.roles: [master, data]  # 角色配置
discovery.seed_hosts: ["host1:9300", "host2:9300", "host3:9300"]
cluster.initial_master_nodes: ["node-1", "node-2", "node-3"]  # 仅首次

yaml

分片分配策略#

Master 负责分片分配决策（Allocation）：

触发时机：
- 新索引创建
- 节点加入/离开
- 手动 reroute

分配规则：
1. Primary 和 Replica 不在同一节点
2. 尽量均匀分布（balance）
3. 尊重 allocation awareness（机架/可用区感知）
4. 延迟分配（节点短暂离开时等待 1min 再重新分配）

plaintext

集群扩缩容#

扩容（加节点）：
1. 新节点配置相同 cluster.name 和 discovery.seed_hosts
2. 启动后自动加入集群
3. Master 自动将部分 Shard rebalance 到新节点

缩容（移除节点）：
1. 先排除节点: PUT /_cluster/settings { "exclude._name": "node-4" }
2. 等待分片迁移完成
3. 关闭节点

plaintext

面试回答（2分钟版）

ES 集群由 Master 节点管理元数据和分片分配。7.x 以后用基于 Raft 的选主协议替代了旧版 Zen Discovery，自动防脑裂，不再需要手动配置 minimum_master_nodes。建议 3 个专用 Master 节点（不存数据），多数票 quorum=2 才能选出 Master。集群健康三色：Green 全部正常，Yellow 主分片正常但有副本未分配（通常是节点数不够），Red 有主分片缺失需紧急处理。分片分配由 Master 决策，规则是 Primary 和 Replica 不同节点、尽量均匀、支持机架感知。扩容只需新节点配置相同 cluster.name 启动即可自动加入并 rebalance；缩容先 exclude 排除节点等分片迁移完再关闭。

追问与易错

追问方向：

“怎么避免脑裂？”→ 奇数 Master 节点 + 7.x 内置 Raft 协议 + 专用 Master
“Master 挂了怎么办？”→ 其他 Master-eligible 节点自动选举新 Master，服务短暂不可用（秒级）
“Yellow 状态怎么处理？”→ 通常是节点数少于副本需求，加节点或减少副本数
“怎么做跨机房部署？”→ allocation awareness 按 rack/zone 分布副本

易错点：

❌ “Master 节点处理所有请求”——Master 只管元数据，数据读写由 Data 节点处理
❌ “Yellow 就是有问题”——单节点集群必然 Yellow（副本无处分配），不影响读写
❌ “节点挂了数据就丢了”——有 Replica 就不会丢，Replica 会提升为 Primary