Elasticsearch 磁盘空间异常：一次成功的故障排除案例分享

故障现象

近日有客户找到我们，说有个 ES 集群节点，磁盘利用率达到了 82% ，而其节点才 63% ，想处理下这个节点，降低节点的磁盘利用率。

起初以为是没有打开自动平衡导致的，经查询，数据还是比较平衡的。 利用率较高的是 76 节点，如果 76 节点的分片比其他节点多，好像还比较合乎逻辑，但它反而比其他节点少了 12-15 个分片。那是 76 节点上的分片比较大？

索引情况

图中都是较大的索引，1 个索引 25TB 左右，共 160 个分片。

分片大小

节点 64 节点 77 节点 75 问题节点 76 可以看出分片大小没有出现较大的倾斜，分片大小和数据平衡的原因都被排除。

换个方向思考，节点 76 比其他节点多使用了磁盘空间 8 个 TB 左右，集群最大分片大小约 140GB ，8000/140=57 ，即节点 76 至少要比其他节点多 57 个分片才行，啊这...

会不会有其他的文件占用了磁盘空间？

我们登录到节点主机，排查是否有其他文件占用了磁盘空间。

结果：客户的数据路径是单独的数据磁盘，并没有其他文件，都是 ES 集群索引占用的空间。

现象总结

分片大小差不多的情况下，节点 76 的分片数还比别的节点还少 10 个左右，它的磁盘空间反而多占用了 8TB 。

这是不是太奇怪了？事出反常必有妖，继续往下查。

原因定位

通过进一步排查，我们发现节点 76 上有一批索引目录，在其他的节点上没有，而且也不在 GET \_cat/indices?v 命令的结果中。说明这些目录都是 dangling 索引占用的。

dangling 索引产生的原因

当 Elasticsearch 节点脱机时，如果删除的索引数量超过 Cluster.indes.tombstones.size，就会发生这种情况。

解决方案

通过命令删除 dangling 索引：

DELETE /\_dangling/<index-uuid>?accept_data_loss=true

最后

这次的分享就到这里了，欢迎与我一起交流 ES 的各种问题和解决方案。

关于极限科技（INFINI Labs）

极限科技，全称极限数据（北京）科技有限公司，是一家专注于实时搜索与数据分析的软件公司。旗下品牌极限实验室（INFINI Labs）致力于打造极致易用的数据探索与分析体验。

极限科技是一支年轻的团队，采用天然分布式的方式来进行远程协作，员工分布在全球各地，希望通过努力成为中国乃至全球企业大数据实时搜索分析产品的首选，为中国技术品牌输出添砖加瓦。

官网：https://infinilabs.cn