elasticsearch 段合并带来的惊心动魄的生产事故用生产集群数据的截图带你重新认识段合并

本文链接：https://blog.csdn.net/star1210644725/article/details/116560953

看过不少的elasticsearch优化的文章，都说到段合并会带来不错的效果。

前几天阿里技术专家，欧阳楚才给我们做了一次技术分享。在分享会上，他也有提到段合并带来的优化效果可能会有两三倍。

这让我蠢蠢欲动，回来又补了一些段合并的知识。我每次看一个问题，都会把谷歌搜出来的前三页都看一遍。这些文章都在说段合并有多好，以及仅仅提到段合并会占用IO，可是没有提段合并的问题。段合并有哪些坑呢？如何避坑呢？

我用一次生产环境的数据，给大家还原一下段合并的过程，以及没有注意到的点，造成的生产事故。从截图证据中，我们一起看一下段合并需要注意什么。先讲证据，然后后边我会总结一下段合并的原理。

事故还原

从服务器监控，钉钉推送消息报磁盘空间超过设定的阈值开始！生产集群的监控，已经看到磁盘空间触发设定的报警阈值了。时间是5月8号下午四点。

磁盘报警本来设定的百分之八十，一开始我知道是在进行段合并，想着很快就会恢复。但是到今天5月九号，我去看了一下段合并的情况。看到的下图的情况。这里需要知道ES到磁盘的阈值是百分之八十五。超过以后就只能读索引了，不能再操作任何索引了。还是看图说话：右上角可以看到，在上升了一段时间以后，从5月8号报警没过多久，就到达磁盘阈值85%了。所以接下来有了一段很长时间的水平线阶段，这段时间是五月八号晚上。

另外一个事实：网上没有任何一篇文章去说，手动触发的段合并，需要的可用磁盘空间，至少是当前执行段合并索引的一倍以上（本文画的第一个重点），在执行之前，考虑清除，你的集群是否有足够可用的磁盘空间在做这个操作。否则就会造成下图这个情况，到达磁盘阈值，段合并执行不下去了，想回退都没的选。还是从下图可以看到，我在手动执行了段合并以后。磁盘空间基本上翻了一倍。从下图的9T到了将近18T。此时并没有结束，恰好触动了磁盘的百分之八十五的阈值。还要我们线上只有晚上才会写数据。不让这将是一个非常大的事故了！本次触发磁盘阈值的事故，没哟带来损失，但是给我一个警告。

解决这一个事故

当我看到上图这个情况的时候，我紧急的干掉了副本（为什么敢干掉副本，不怕数据丢失吗？不怕，我是有索引快照的），可以等看到我干掉了副本以后，磁盘空间立刻得到了释放，并且释放了大概8T，而我本来副本实际上也就4.5T，这说明副本跟着一起进行段合并了。大家看到我的单个索引的占用磁盘空间到了9T多，这是因为我设置了一个副本。实际上我的索引占用了是4.5T。这里将是本文第二个画的重点：段合并之前，最好先干掉副本。否则副本也要跟着去执行段合并。这会给集群带来双倍的代价，包括CPU，IO以及磁盘。我们可以等段合并完成以后，再恢复副本。恢复副本花费的时间，远比段合并的时间小的多，代价更小一点。干掉副本以后，释放了足够多的磁盘空间。我重新执行了一下强制段合并。没过多久，如下图左下角已经看到段的个数正在减少。这说明，我昨天触发的段合并在受到磁盘阈值限制以后，在我重新触发了段合并，它又续上了。

后续段合并的效果：两张图，每张图的右上角是磁盘空间，左下角是段的个数。看到在骤降，心里瞬间舒服了很多。

这是段合并最后的效果了：

几点需要主要注意的：

段数并没有降低到我的预期！我期望的是能够均匀，并且数量更少。
另外磁盘空间的释放也没有带来预期的效果，明显看到段合并之前的磁盘占用空间更少。这次段合并反而多了。这不符合预期结果，我肯定是踩到哪里的坑了。因为，按说段合并会清除掉之前删除的文档，那按说磁盘空间应该降低才对。可是这明明大于段合并之前。
不过搜索效果确实要比之前好了挺多。

这里我得出一个结论，最好最好不要频繁更新你的索引，特别是巨大的索引。这会带来很多的段数，并且段合并需要花费巨多的时间，严重影响到业务。频繁的更新，是es搜索性能降低的杀手！因为它带来了更多的段。

另外我又看了一下生下来的这些段具体什么情况：还是有一些大段没有在段合并的时候清除掉删除的文档。我猜测的是：这是因为大的段已经不能再合并了。所以这更加确定，索引不能频繁的更新。另外也验证了官网说的，最好不要对后续会改变的索引进行段合并。下图，就是我付出的代价。我准备用reindex的方式，重新建造一个索引。然后把久的索引清除掉。