线上项目elasticsearch数据丢失原因排查记录

今天早上突然发现线上的数据丢失，然后排查统计数据库 数据正常。那就是搜索服务器elasticsearch数据不全，然后开始排查，发现elasticsearch根据ID 查询直接报错，然后查看elasticsearch健康值，curl http://127.0.0.1:9200/_cat/health?v   red     active_shards_percent   %40    。然后 free -h  内存有空间，  df -h  磁盘也还有一半空间。

然后开始百度。。。。。。。。。。

慌乱中执行了这条命令 直接导致线上项目报错，被迫 项目 维护更新。
curl -XPOST "http://127.0.0.1:9200/你的索引名称/_close"

然后：curl -XPOST "http://127.0.0.1:9200/你的索引名称/_open"   开启 后项目正常。

然后继续百度 查导致 elasticsearch 异常的真正原因。。。。

df -i   User 100%  原来是索引节点inode爆满。 

然后查看最有可能 导致centos 节点爆满的文件夹 （session保存的文件夹） find ./ |wc -l  265万个文件 。。。。。

这里清理一定注意不能  rm -rf  ./*  

清理文件的最安全可行的办法 

1 查看 30 天前的文件数   ： find . -type f -mtime +30 |wc -l  

如果是0 就查25天前的文件数 ： find . -type f -mtime +25 |wc -l  

最后一天一天的开始清理  ：  find . -type f -mtime +30 -exec rm -f {} \;   find . -type f -mtime +29 -exec rm -f {} \; 。。。。。

也可以写定时任务清理。  最后 写一个 定时清理 7 天前的  session 文件 的定时任务。

df -i  user   40%     OK

curl http://127.0.0.1:9200/_cat/health?v   green    OK

菜鸟一个，自己的亲身经历，一个是记录下来方便以后查看，二是分享给遇到同样问题的人。

你的 elasticsearch red  不一定是这个问题。