2.3 Elasticsearch-集群状态：Green/Yellow/Red 排查思路

Elasticsearch集群红黄排查指南

最新推荐文章于 2025-12-04 14:41:04 发布

原创最新推荐文章于 2025-12-04 14:41:04 发布 · 28 阅读

0 ·

CC 4.0 BY-SA版权

CC BY-NC-SA 3.0

文章标签：

#elasticsearch #大数据 #搜索引擎

elasticsearch 专栏收录该内容

25 篇文章

订阅专栏

在这里插入图片描述
2.3 Elasticsearch-集群状态：Green/Yellow/Red 排查思路
——让“红绿灯”不再只是玄学

0. 状态速览：一张表先背下来

状态	字面含义	能否读写	能否继续分配 shard	典型触发场景	用户体感
Green	所有主副分片都就位	正常读写	是	集群健康	无感知
Yellow	主分片就位，但有副本未分配	正常读写	部分受限	节点离线、磁盘水位、索引设置	有告警，业务无影响
Red	至少一个主分片丢失	只能读不能写缺失主分片的索引	否	多节点离线、索引损坏、分配失败	直接报错，业务受损

1. 排查总纲：30 秒定位“谁红了”

GET _cluster/health?level=indices
一眼看索引维度，把 Red/Yellow 的索引名记下来。
GET _cluster/allocation/explain?index=<idx>&shard=<id>&primary=true
官方提供的“一站式”诊断接口，90 % 的场景直接给出原因。
如果第二步返回“cannot allocate because…” 就顺着 decision 列表往下读；
如果返回 404，说明集群自己也不知道该 shard 在哪，跳第 3 节“Red 专项”。

2. Yellow 集群：99 % 是副本数 > 存活节点数

2.1 最常见模板

3 节点集群，索引 number_of_replicas=2 → 需要 3 份副本，总共 3×2=6 个分片，但集群只有 3 节点，必然分配不齐。
节点离线一台，副本数仍保持 1，也会 Yellow。

2.2 一键修复

PUT */_settings
{
  "number_of_replicas": 0          // 先降到 0，立刻 Green
}

随后按需调大，或者把节点加回来。

2.3 磁盘水位踩线

GET _cat/allocation?v 看 disk.indices 和 disk.percent，当某个节点超过 cluster.routing.allocation.disk.watermark.low（默认 85 %）时，ES 不再向该节点分配任何 shard，副本悬在空中变成 Yellow。

临时方案：调高阈值

PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.disk.watermark.low": "90%",
    "cluster.routing.allocation.disk.watermark.high": "95%"
  }
}

根治：加磁盘或加节点。

2.4 单节点开发环境必踩的坑

开发机只起了一个 ES 进程，却用了 number_of_replicas=1，永远 Yellow。
官方推荐模板：

PUT _template/single-node
{
  "index_patterns": ["*"],
  "settings": {
    "number_of_replicas": 0
  }
}

3. Red 集群：主分片真的丢了

3.1 确认“丢”还是“暂时没分配”

GET _cat/shards?v&h=index,shard,prirep,state,unassigned.reason

UNASSIGNED 且 prirep=p，状态 UNASSIGNED，reason 常见：
– NODE_LEFT：节点离线
– ALLOCATION_FAILED：分配失败超过重试上限
– CORRUPTED：段文件校验失败

3.2 节点离线场景

节点还能启动
直接重启节点，ES 会把磁盘上的 shard 直接拉起来，集群自动回到 Yellow→Green。
节点彻底挂掉且数据目录丢失
进入“抢救 or 接受丢数据”分支：
- 索引不重要：

DELETE 坏索引

索引必须恢复：
从快照还原，或者 elasticdump/logstash 从备份集群重新写回。

3.3 分片损坏场景

日志里能看到 CorruptIndexException 或 checksum failed。

先尝试 /_cluster/reroute 命令强制重分配：

POST _cluster/reroute
{
  "commands": [
    {
      "allocate_stale_primary": {
        "index": "shop-order",
        "shard": 2,
        "node": "node-3",
        "accept_data_loss": true
      }
    }
  ]
}

该命令把“过时副本”提拔成主分片，可能丢数据，务必确认业务可接受。

若所有副本都损坏，只能删索引或从快照恢复。

3.4 分配失败重试耗尽

GET _cluster/allocation/explain 返回 max_retry [5] exceeded。

先解决根因（磁盘、mapping 冲突、Field limit）。
再手动重试：

POST _cluster/reroute?retry_failed=true

4. 黄/红场景下的可观测三板斧

日志
cluster.name.log 里搜 failed to create shard/corrupt，直接给出行号。
Metricbeat 监控
重点看 elasticsearch.cluster.stats.status=red 的告警，配合 elasticsearch.node.stats.fs.available 预判磁盘踩线。
Kibana Stack Monitoring
左侧 “Elasticsearch → Indices” 视图，红色索引会高亮，点进去能看到 unassigned reason，省去手写 cat API。

5. 生产级 checklist（复制即可贴 Confluence）

索引模板默认副本数 ≤ 节点数 – 1
磁盘水位 low/high 分别 ≤ 85 %/90 %，并配 flood_stage 告警
快照策略每日自动，Red 时可直接 restore
节点优雅下线：

PUT _cluster/settings
{"transient":{"cluster.routing.allocation.exclude._name":"要下架的节点"}}

等待 GET _cat/shards 无该节点 shard 后再 kill 进程，杜绝人为 Red。

集群重启顺序：先 master-eligible，再 data，最后 coordinate，避免 master 未形成共识导致 shard 乱飞。

6. 小结

Yellow 是“副本没地方放”，Red 是“主分片真的丢了”。
用 /_cluster/allocation/explain 一把梭，90 % 场景都能把原因定位到“磁盘、节点、副本数、损坏”四大类。
剩下的 10 %，先删索引保集群，再从快照恢复保业务——集群先 Green，再谈数据。
更多技术文章见公众号: 大城市小农民