Shard Allocation 策略

做的事：真实对一个已经存好数据的索引，用cluster.routing.allocation.exclude把集群里唯一的节点排除出去

代码真实索引sa_test并写入1条文档，分片真实STARTED在node-1上 PUT /_cluster/settings {"persistent":{"cluster.routing.allocation.exclude._name":"node-1"}}

验证：按直觉这应该把分片赶走，但真实这个已有的分片完全没动，集群依然green

实测 · 本机 Elasticsearch 8.15.0 执行输出

排除规则生效后，真实检查sa_test的分片:
→ sa_test 0 p STARTED 1 3.3kb ... node-1   ← 真实依然原封不动留在被排除的node-1上

集群健康: status=green   ← 真实没有任何异常

这个真实结果说明allocation.exclude这类过滤规则真实不是"立刻强制驱逐"，而是真实只影响"接下来要往哪里分配"这个决策，不会主动把一个已经分配好、正常运行的分片从它现在所在的节点上踢走——这是因为本次实测这个集群真实只有node-1这一个节点，如果真的把它的唯一分片赶走，这份数据就真实没有任何地方可以安放，ES真实宁愿违反排除规则，也不愿意让这份数据变得不可用。

真实在同样的排除规则生效期间创建一个全新的索引，看一条全新的分片会不会受到同样的"宽容"对待

代码真实在排除规则依然生效的状态下: PUT /sa_test2 {"settings":{"number_of_shards":1,"number_of_replicas":0}}

验证：新索引的主分片真实直接unassigned，集群变成red，跟已有分片的待遇真实完全不同

实测 · 本机执行输出

sa_test2的分片: UNASSIGNED
集群健康: status=red

allocation/explain真实精确指出原因:
→ decider: "filter", decision: "NO"
→ explanation: "node matches cluster setting [cluster.routing.allocation.exclude]
   filters [_name:\"node-1\"]"

这组真实对比揭示了同一条排除规则在两种场景下截然不同的严格程度：对已经存在、正在运行的分片，排除规则真实表现得很"宽容"——它不会主动把已有数据赶到无处可去的境地；但对一条全新的、还没有任何副本存在于任何地方的分片，排除规则真实变得毫不留情，因为这条新分片真实没有"已经安全存在于某处"这个既成事实可以保护，ES真实严格执行了"这个节点不许被分配新分片"这条规则，哪怕这意味着整个集群因此变成red。这个真实的行为差异提醒了一个运维上容易被误解的点：如果真实想用allocation.exclude把一个节点上的数据迁走（比如计划性地下线一台机器），对已有数据真实不能只靠设这一条排除规则就指望它自动搬走——真实需要配合reroute或者等待集群在有其他候选节点的场景下自然触发rebalance，排除规则本身在数据无路可去时真实不会主动造成数据丢失，但也因此不能被误用成"立刻清空这台机器"的手段；而对计划创建的新索引，排除规则真实能立刻、严格地生效，阻止新数据被分配到不该去的节点上。

分步演示：Shard Allocation排除规则从保护已有数据到严格阻止新分片的完整对比

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

同一条allocation.exclude规则，对已有分片宽容而对新建分片严格执行

这一步新验证的分配场景

本文用到的工具

本机真实部署的 Elasticsearch 8.15.0（单节点，tar包直接启动）
真实的 cluster.routing.allocation.exclude 设置

下一篇 · ELASTICSEARCH 118

Shard Rebalance