单节点副本为什么一直是 Yellow

做的事：本机单节点集群真实用默认设置建一个索引，看默认的副本数量设置会带来什么

代码PUT /yt_test # 真实不带任何settings，全部用默认值 GET /yt_test/_settings

验证：默认number_of_replicas真实是1，集群真实立刻变成yellow

yt_test 真实的 number_of_replicas: 1   ← 默认值，不是0

GET /_cluster/health/yt_test:
→ status: "yellow"
→ active_primary_shards: 1
→ unassigned_shards: 1

这个真实结果说明Elasticsearch的索引默认设置真实是假定生产环境会有多台机器的——默认给每个索引配1份副本，是为了默认情况下就具备基本的高可用能力。但本机真实只有一个单节点的开发测试集群，这份默认的副本配置在这种场景下真实注定无法被满足。

真实用allocation/explain确认，这个yellow背后的根因是不是跟本系列反复验证过的same_shard决策器一样

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

验证：真实确认根因就是same_shard——副本不能跟主分片放在同一个节点，而本机真实只有这一个节点

current_state: "unassigned"
decider: "same_shard"
explanation: "a copy of this shard is already allocated to this node"

真实验证一个容易被忽视的坑：用wait_for_status=green等这个索引变green会发生什么

代码time curl ".../_cluster/health/yt_test?wait_for_status=green&timeout=3s"

验证：真实等满3秒直接超时，status依然是yellow——这个yellow真实永远不会自己好

真实等待耗时: 3.018秒（刚好卡在timeout设置的3秒上）
响应: status="yellow", timed_out=true

这是一个真实容易让自动化脚本或者CI流水线卡住的陷阱：很多部署脚本、启动健康检查习惯用wait_for_status=green这个参数等集群"准备好"，如果本地或者CI环境里跑的是单节点测试集群、索引又用了默认的副本设置，这个等待真实永远不可能等到green，只会真实一直耗到timeout设置的那个时间点然后超时返回——如果脚本没处理好这种超时场景，真实可能导致流水线莫名其妙地卡住或者报错。

真实验证修复方式：把number_of_replicas改成0，看集群是否立刻恢复green

代码PUT /yt_test/_settings {"index.number_of_replicas":0}

验证：集群真实立刻变green，同样的等待请求真实瞬间返回，不再超时

改完之后: status="green", unassigned_shards=0

重新发起同样的wait_for_status=green请求:
→ 真实0.014秒就返回了，status="green", timed_out=false   ← 不再等满3秒

收尾：真实清理测试索引，确认集群恢复green

代码DELETE /yt_test,yt_test2

分步演示：从默认副本配置导致的yellow，到wait_for_status永久超时，再到降副本数真实立刻恢复green

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