Elasticsearch 磁盘空间异常:一次成功的故障排除案例分享
Easysearch
Elasticsearch
2024-08-08

故障现象 #

近日有客户找到我们,说有个 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 的各种问题和解决方案。

标签
Easysearch x
Gateway x
Console x