我们的Elasticsearch集群有两个数据目录。我们最近重新启动了群集中的所有节点。成功重启过程后，我们观察到少数节点上的磁盘空间使用量增加。当我们检查数据目录中的文件夹时，我们发现存在孤立的分片。
例如，孤立的碎片“15”存在于位置data_dir0 / cluster_name / nodes / 0 / indices / index_name / 15，而同一碎片“15”的一个副本存在于其他数据目录内的同一节点上，这里是data_dir1 / cluster_name / nodes / 0 / indices / index_name / 15。来自data_dir1的这个分片“15”也包含在集群元数据中，因此，我们假设data_dir0中的分片“15”是孤立的分片，必须由Elasticsearch删除。但是，即使在上次重启后的6天内，Elasticsearch还没有删除孤立的碎片。
我们发现此主题https://discuss.elastic.co/t/old-shards-on-re-joining-nodes-useful/182661与我们的问题有关，但它没有帮助我们，因为在ES中没有处理孤立的碎片。我们还在弹性论坛上提出了问题，但我们没有得到快速回复。所以，我在这里问它，因为堆栈溢出有更大的社区。
答案 0 :(得分：1)
您正在运行哪个版本的Elasticsearch？
您的群集是否为绿色？如果是这样，那么在初始化期间Elasticsearch应删除这些分片文件。但是，如果该节点在节点重新加入群集时具有未分配的副本，则Elasticsearch将不会删除磁盘上预先存在的分片文件。
如果您不需要分片，可以手动删除目录。或者您可以尝试在节点上重新启动Elasticsearch并让它为您删除文件。
答案 1 :(得分：1)
这也发生在我们的集群中，我们运行弹性6.1.3。一个特定的节点使用了88％的磁盘，这似乎是我们生产索引上先前的重定位留下的碎片。
要解决此问题，我在节点上停止了Elasticsearch（确保其他数据节点上有足够的磁盘空间），让弹性的重定位完成其工作。完成并重新平衡后，删除索引文件夹并再次启动Elasticsearch，这非常轻松。
答案 2 :(得分：0)
我们也在这里获得了Elastic论坛的帮助https://discuss.elastic.co/t/old-shards-not-deleted-upon-relocation/71161/6
重新启动节点没有帮助，我们不想手动删除文件夹。因此，我们将逐个替换受影响的节点。
@chani如果您能提供手动删除建议的任何官方链接，那就太棒了。