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