故障现象

近日有客户找到我们，说有个 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

Elastic Podcast 来啦！让我来先给大家介绍一下什么是 Elastic Podcast，这是一档新的由 Elastic 中文社区发起的谈话类播客节目，我们会定期邀请 Elastic 软件的用户，一起来聊一聊他们与 Elastic 的故事，会围绕各种有意思的话题进行讨论，比如具体的行业应用实践啦、实际的架构部署啦、来自一线的实战经验分享等等。他山之石可以攻玉，相信会对你有帮助。

好啦，回到正题，第一期有什么呢，让我们一起走进位于上海的 DerbySoft（德比软件），德比软件是一家专注于旅游酒店行业管理系统的公司，其客户分布全球，每天有上千台服务器在不停的产生日志，让我们来听听德比软件的解经理给大家介绍，他们是如何用不到 20 台的 Elasticsearch 服务器来支撑总量 800 亿的日志分析，以及了解他们具体是如何使用 Kibana，以及在使用过程中的各种经验和分享。

主持人：

Elastic 技术布道师，曾勇（Medcl）。

嘉宾：

解恒跃，德比软件研发一部高级技术经理，从事软件开发和管理工作 12 年；擅长 Java 相关技术，webservice，微服务，敏捷软件开发。

收听方法

可以点击下面的任意链接来收听（时长约 30 分钟）：

• SoundCloud： https://soundcloud.com/elastic-cn/elastic-podcast1...
• 喜马拉雅：http://m.ximalaya.com/111156131/sound/82918649
• 蜻蜓 FM：https://www.qingting.fm/channels/244978/programs/8916389

关于 DerbySoft：

德比软件创立于 2002 年，是专业从事旅游网络营销系统的技术服务公司，近 400 人的员工分布于上海、北京、南京、达拉斯、伦敦、东京等地。是拥有全部产品自主知识产权并为全球酒店行业提供软件服务的公司，是目前全球提供酒店对接服务最好，并且对接上线成功案例最多的公司。https://www.derbysoft.com/