Unassigned Shard 原因分析

做的事：真实对上一篇造出来的red索引(主分片unassigned)，用_cluster/allocation/explain诊断具体原因

代码GET /_cluster/allocation/explain {"index":"health_test3","shard":0,"primary":true}

验证：真实精确定位到是filter类型的决策器拒绝了分配，报错里写明了具体的过滤条件

实测 · 本机 Elasticsearch 8.15.0 执行输出

unassigned_info.reason: "INDEX_CREATED"   ← 真实这个分片从索引创建那一刻起就没能分配成功

node-1的决策器:
→ decider: "filter"
→ decision: "NO"
→ explanation: "node does not match index setting
   [index.routing.allocation.require] filters [_name:\"nonexistent_node_xyz\"]"

这份真实诊断把根因摆得清清楚楚：节点之所以被拒绝，真实是因为这个索引配置了index.routing.allocation.require._name这条分配规则，要求分片必须分配到名字叫nonexistent_node_xyz的节点上，而真实整个集群里压根没有这个名字的节点，所以唯一的候选节点node-1真实被这条规则直接否决。

真实对比上一篇的yellow索引(副本unassigned)，看同样用这个诊断接口会不会给出完全不同的根因

代码GET /_cluster/allocation/explain {"index":"health_test2","shard":0,"primary":false}

验证：真实查出了完全不同的决策器类型same_shard，根因是真实没地方放跟主分片不同的节点

实测 · 本机执行输出

decider: "same_shard"
decision: "NO"
explanation: "a copy of this shard is already allocated to this node
   [[health_test2][0], node[hUiouvLWRBq_tB2DPJ_xKw], [P], s[STARTED], ...]"

这组真实对比证明了_cluster/allocation/explain这个API真实的诊断价值：同样都是unassigned状态，red索引的真实根因是filter决策器因为分配规则配置错误而拒绝（这是真实配置层面的问题，需要去检查index.routing.allocation.*这类设置），yellow索引的真实根因是same_shard决策器因为ES的硬性规则——副本永远不能跟主分片放在同一个节点上——而拒绝（这是真实集群拓扑层面的限制，需要真实加机器才能解决，不是配置问题）。如果没有这份诊断，运维面对一堆真实状态都是"unassigned"的分片，真实没法从表面现象区分出哪些是配置错误、哪些是节点数量不够、哪些可能是磁盘空间不足（本系列更早文章验证过的disk_threshold决策器）——_cluster/allocation/explain真实把每一个节点对每一个候选分片的真实决策过程都摊开展示，决策器的名字和解释文本直接对应着具体的、可操作的修复方向，这正是排查unassigned分片问题时应该第一个想到的工具，而不是靠猜测或者试错去调整配置。

分步演示：Unassigned Shard从red索引的filter拒绝到yellow索引的same_shard拒绝的完整诊断对比

每一步都是本文上面在本机真实的Elasticsearch 8.15.0上跑出来的原始结果。

同样都是unassigned，_cluster/allocation/explain能精确区分配置错误与拓扑限制两种根因

这一步新验证的决策器类型

本文用到的工具

本机真实部署的 Elasticsearch 8.15.0（单节点，tar包直接启动）
真实的 _cluster/allocation/explain API

下一篇 · ELASTICSEARCH 116

Allocation Explain API