把 number_of_replicas 从 1 改成 2，300 个副本分片一直 INITIALIZING，一晚上过去还是 300。节点 CPU 只有 20%，磁盘还剩一半空间。乍看像缓存或者权限的锅，追下去往往不是。
PUT orders/_settings
{"index": {"number_of_replicas": 2}}
GET _cluster/allocation/explain
GET _cat/recovery?v&active_only=true
追下去是这么回事：副本要跨节点分配，节点数不够或者 total_shards_per_node 卡住时，分片会停在等待状态。大量分片同时初始化还要受并发恢复数限制，一次只推进两个。看着像卡死，实际是在排队。
「副本数调整卡住」这类改动最怕改一半，回滚脚本先准备好，再动生产。测试环境和线上的差别，往往就在版本号和那几行被忽略的配置上。
线上出问题先对时间点，跟发布、备份、任务执行的时刻排一排，能省掉一半功夫。日志级别临时调高可以，记得改回去，长期开着既占磁盘又掩盖真问题。
权限不要一口气开到最大，先加到够用再往上试，范围小才好收。
具体做法是，用 allocation/explain 确认是被节点数还是阈值挡住；按节点数算清楚能承载的副本上限；临时提高 node_concurrent_recoveries 加快排队；确认 allocation.enable 没有被设成 none。
验收就看一点，unassigned_shards 逐步归零，health 从 yellow 变 green，_cat/recovery 有速度输出。