Elasticsearch 集群变为 RED，表示至少一个主分片不可用。此时部分索引可能无法读取或写入，必须优先保护现场并确认数据副本，不能一看到 RED 就删除索引或强制分配分片。
一、快速判断影响
curl -s http://127.0.0.1:9200/_cluster/health?pretty
curl -s 'http://127.0.0.1:9200/_cat/nodes?v'
curl -s 'http://127.0.0.1:9200/_cat/indices?v&health=red'
curl -s 'http://127.0.0.1:9200/_cat/shards?v'重点确认：
哪些索引的主分片为
UNASSIGNED；是否有节点离线或频繁加入、离开集群；
节点磁盘是否超过水位；
集群管理节点是否稳定；
最近是否发生扩缩容、重启、版本升级或存储故障。
二、解释未分配原因
curl -s -X GET 'http://127.0.0.1:9200/_cluster/allocation/explain?pretty' \
-H 'Content-Type: application/json' \
-d '{"index":"your-index","shard":0,"primary":true}'该接口会说明分片为何不能分配，例如磁盘水位、分配过滤、节点属性不匹配、副本不足或历史分片副本失效。先读懂解释，再决定操作。
三、常见根因
节点宕机，唯一有效的主分片副本随节点离线。
磁盘超过 low、high 或 flood-stage 水位，分片停止迁移或索引被只读保护。
分片数量过多，节点资源不足，恢复速度极慢。
分配规则、机架感知或节点角色配置不合理。
存储损坏、文件权限异常，或节点使用了错误的数据目录。
集群重启顺序和最小主节点配置不当，导致集群状态不稳定。
四、应急恢复思路
节点只是暂时离线：优先恢复原节点和原数据目录。
磁盘水位过高：释放可确认的无用空间或扩容，等待分片自动恢复。
有可用副本：确认分配限制后恢复正常分配。
无有效副本：优先从快照恢复；强制分配陈旧主分片可能造成数据丢失，必须经过业务确认。
恢复过程中持续观察 pending tasks、recovery 和集群日志，避免并发执行大量 reroute 操作。
五、长期治理
配置并验证快照仓库，定期做恢复演练。
控制单节点分片数、单分片大小和索引生命周期。
对磁盘水位、未分配分片、节点离线和集群状态设置告警。
生产集群至少保留合理副本，并将副本分散到不同故障域。
扩容和版本升级前检查分片迁移空间与恢复带宽。
处理 RED 集群时，优先级应是“确认数据安全 → 找到不能分配的原因 → 恢复有效副本 → 再做容量治理”。