故障現象
近日有客戶找到我們，說有個 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 的各種問題和解決方案。
