Elasticsearch 集群 yellow — 副本分片未分配的原因

通过分配解释、未分配分片列表与磁盘水位排查 Elasticsearch yellow 状态，区分单节点预期行为与真正的副本放置故障。

现象

GET _cluster/health 返回 status: yellow；unassigned_shards 长期大于 0；日志提示副本分片无法分配；搜索和写入都正常，但集群始终不变绿。

诊断

先确认是副本缺失而不是主分片丢失：

curl -s 'localhost:9200/_cluster/health?pretty'
curl -s 'localhost:9200/_cluster/allocation/explain?pretty'
curl -s 'localhost:9200/_cat/shards?v&h=index,shard,prirep,state,unassigned.reason' | grep UNASSIGNED
curl -s 'localhost:9200/_cat/allocation?v'

yellow 表示所有主分片可用，只是至少一个副本没有落位；red 才是主分片缺失，处理方式完全不同。allocation/explain 的 deciders 会逐项给出决策，常见原因包括磁盘水位超限、分配过滤规则、节点缺少 data 角色。unassigned.reason 为 REPLICA_ADDED 说明请求了副本但无处安放，NODE_LEFT 表示承载节点已离开。_cat/allocation 可核对各节点剩余空间是否高于低水位。

修复

单节点开发环境本就无法放置副本，直接把副本数设为 0，并把 yellow 视为预期状态：

curl -X PUT 'localhost:9200/*/_settings' -H 'Content-Type: application/json' \
  -d '{"index": {"number_of_replicas": 0}}'

多节点集群则应清理磁盘、增加 data 节点、移除过期的 cluster.routing.allocation.exclude 配置，然后执行 POST /_cluster/reroute?retry_failed=true 重试。副本数要与可用 data 节点数匹配，不要为了变绿而调低水位或手工迁移主分片。

验证

再次查询 _cluster/health，确认 status 为 green 且 unassigned_shards 为 0；_cat/shards 中所有 primary 与 replica 都应为 STARTED。若确实采用单节点，应把 yellow 记录为已接受状态，并改为对 red 或未分配主分片告警，避免真正的可用性故障被熟悉的颜色掩盖。