ES索引异常关闭怎么救？三大诱因拆解，数据恢复全攻略
一、半夜索引突然消失？先看这三个罪魁祸首
上周隔壁王哥的电商平台凌晨崩了，ES日志里整整齐齐少了6个索引。后来发现是磁盘空间飙到95%触发自保机制，这事儿跟汽车油表亮红灯就限速一个道理。
三大常见元凶对比：
| 异常类型 | 触发条件 | 危险指数 | 典型特征 |
|---|---|---|---|
| 磁盘空间不足 | 使用率＞90%持续30分钟 | ★★★★★ | 索引变只读，只能删不能改 |
| ILM策略失控 | 生命周期策略配置错误 | ★★★☆☆ | 定时批量删除历史索引 |
| 集群节点掉线 | 主分片节点宕机 | ★★★★☆ | 分片状态显示UNASSIGNED |
自问自答：为什么删了数据磁盘还是报警？
因为ES删除数据只是标记逻辑删除，得用_forcemerge清理段文件才释放空间
二、紧急救援五步走：黄金30分钟操作手册
遇到索引异常关闭别慌，照着这个流程能救回90%的数据：
- 速查健康状态：
GET _cluster/health看红黄灯（红色最危） - 定位异常索引：
GET _cat/indices?v&health=red锁定问题索引 - 查看阻塞原因：
GET /索引名/_settings找read_only_allow_delete参数 - 解除写入限制：执行
PUT 索引名/_settings {"index.blocks.read_only_allow_delete":null} - 重建丢失分片：
POST _cluster/reroute?retry_failed=true手动分配分片
血泪教训：有家公司直接重启集群，结果导致分片混乱，数据恢复多花了8小时！
三、防患于未然：这三个监控指标要盯 ***
运维 *** 必装的报警器：
- 磁盘水位线：设置85%预警，90%自动清理30天前索引（用Curator工具）
- 分片分配率：
GET _cluster/stats关注unassigned_shards数值 - ILM策略日志：给每个生命周期策略配置独立日志通道
自动化脚本示例：
bash复制#!/bin/bash# 每天凌晨1点检查磁盘if df -h | grep elasticsearch | awk '{print $5}' > 85%; thencurl -X DELETE "旧索引-$(date -d '30 days ago' +%Y.%m)*"fi
干这行八年，见过太多人把ES当普通数据库使。记住两个铁律：定期给_cat/indices做体检比事后救火强十倍；集群规模超20节点必须上专用监控（比如Elastic Alert），别再用土法炼钢的脚本了。现在你知道为什么大厂招ES运维开月薪3万了吧？