监控显示 OpenSearch cluster status 为 red，Magento 分类页或搜索间歇 500。Red 表示至少一个 primary shard 未分配，不是简单的“副本不足”；依赖该主分片的索引可能无法查询或写入。
先确定影响范围
GET /_cluster/health
GET /_cat/indices?v&health=red
GET /_cat/shards?v&h=index,shard,prirep,state,unassigned.reason,node只读获取集群状态，记录 Magento 当前别名指向哪些索引。不要看到 red 就删除全部索引，集群里可能还有其他应用数据。
让集群解释为何不分配
GET /_cluster/allocation/explain
{
"index": "affected_index",
"shard": 0,
"primary": true
}常见原因包括节点离线、磁盘超过水位、分片副本策略与节点数不匹配、索引数据损坏或 allocation filter。不同原因处理完全不同。
磁盘满时先停止写入压力
Magento 全量重建会创建新索引，短期占用旧索引之外的额外空间。磁盘已触发 flood stage 时反复 reindex 只会恶化。先释放可确认无用的快照/日志/旧索引，或扩容节点，再解除写保护并重建。
是否可以由 Magento 重建
目录搜索索引通常可由数据库重新生成，但前提是 red 的确只影响可重建 Magento 索引，并且集群恢复到可分配状态。先保留别名和索引清单，在维护窗口运行相关 indexer，确认新索引 green/yellow 且别名原子切换，再清理旧索引。
恢复验证
测试商品保存、增量索引、关键词搜索、分类筛选和排序；观察 unassigned shards、磁盘水位和 JVM/heap。Yellow 在单节点集群可能只是 replica 无处放，但 Red 不能作为稳定状态接受。最后补上节点、容量与快照告警，避免等前台报错才发现主分片丢失。
快照与数据恢复边界
如果 primary shard 因节点磁盘损坏且没有可用副本，重新分配空主分片会永久丢失该索引数据。对 Magento 可重建搜索索引可以从数据库重建；对非 Magento 索引必须从快照恢复。执行 allocation stale_primary 等危险操作前，先确认数据来源和可恢复性。
分片设计
大量小索引和过多 shard 会消耗 heap 与文件句柄；单个巨大 shard 又延长恢复。按商品规模、节点数与重建时间设计 shard/replica，而不是沿用默认值。Magento 部署生成的新索引也需要生命周期清理，避免旧版本一直占磁盘。
应用侧降级
搜索不可用时，是否允许分类页暂时使用有限数据库路径或展示维护提示，应提前设计。临时降级不能绕过价格、权限和库存过滤。错误必须可见，避免给客户返回空结果却显示“没有商品”。
重建期间保护数据库与集群
目录全量索引会同时读取大量商品数据并向 OpenSearch 批量写入。控制批次与并发，观察 reject、GC、磁盘和数据库负载；不要在交易高峰用多个节点同时触发相同 reindex。若别名切换前失败，旧索引应继续服务，并保留可诊断日志。
确认 Magento 使用的是这一个集群
后台配置、环境配置和容器 secret 可能指向不同 endpoint。命令行健康检查 green，而 PHP 实际连另一套 red 集群并不少见。用应用节点解析出的主机、端口、认证与索引前缀核对，输出时对凭据脱敏。
