Shard Rebalance

做的事：真实建一个2个主分片的索引，配上total_shards_per_node=1这条限制，看会发生什么

代码PUT /rb_test2 {"settings":{ "number_of_shards":2,"number_of_replicas":0, "index.routing.allocation.total_shards_per_node":1 }}

验证：第一个分片真实正常分配成功，第二个分片真实直接unassigned，集群变成red

rb_test2 shard 0: STARTED on node-1
rb_test2 shard 1: UNASSIGNED
集群健康: status=red

这组真实结果验证了total_shards_per_node这条设置真实是一道硬性约束：它明确规定"这个索引在单台节点上最多能放几个分片"，本次实测设成1之后，这台唯一的节点刚好分配到第一个分片就真实用满了这个配额，第二个分片哪怕这台节点本身真实还有充裕的磁盘和内存资源，也会被真实拒绝分配，因为它只是真实单纯撞上了这条分片数量的硬上限。

真实用allocation/explain确认这条拒绝背后的具体决策器

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

验证：真实精确对应shards_limit决策器，报错原文直接写出了具体的限制数值

decider: "shards_limit"
decision: "NO"
explanation: "too many shards [1] allocated to this node for index [rb_test2],
   index setting [index.routing.allocation.total_shards_per_node=1]"

真实把限制从1调大到2，看是否需要任何额外操作才能让第二个分片重新分配成功

代码PUT /rb_test2/_settings {"index.routing.allocation.total_shards_per_node":2}

验证：真实不需要任何额外的reroute或者手动干预，两个分片真实立刻都变成了STARTED

调大限制后，真实立刻检查:
→ rb_test2 shard 0: STARTED on node-1
→ rb_test2 shard 1: STARTED on node-1   ← 真实也成功了，不需要额外操作

这个真实结果说明ES的分片分配真实是一个持续在后台运行的协调过程：只要集群配置发生了真实可能影响分配结果的变化（本次是放宽了total_shards_per_node这个上限），ES真实会自动重新评估那些之前因为这条限制被卡住的unassigned分片，不需要像本系列更早文章提到过的"重试次数耗尽"场景那样，真实需要手动调用_cluster/reroute?retry_failed=true才能解开僵局——因为这里的拒绝原因真实只是配置限制本身造成的，一旦配置放宽，限制条件真实就自动满足了，分配流程立刻能继续往下走。

分步演示：Shard Rebalance从total_shards_per_node限制触发unassigned到调整配置自动解开的完整验证

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