截取快照时在elasticsearch上删除/创建时请求超时

Question

我使用nodejs连接到elasticsearch，并使用curator拍摄每小时的快照。

在运行快照操作时，许多create/delete请求在等待30后超时。更严重的问题是，在删除期间，甚至请求超时和客户端假设删除失败，但成功，可能是在超时后发生。这导致了数据的损坏。

我也注意到拍摄快照的时间在线性增长。6个月后，它需要4分钟，尽管它声称备份是增量过程。

我使用了下面的命令来进行备份

/usr/local/bin/curator snapshot --repository mt_es_backup indices --all-indices >> /vol/es/es_backup.log 2>&1

谢谢

Answer 1

馆长不太可能是这里的问题(信息披露:我是Elasticsearch策展人的作者)。

存储库中快照的计数可能会影响快照持续时间，甚至影响快照期间的集群性能。Elasticsearch中的快照在文件级别上是增量的，但所讨论的文件称为段。

段

弹性搜索中最基本的存储单元是段。当文档进入Elasticsearch以进行索引时，它们将被处理为一个缓冲区。当缓冲区被刷新时，它的内容就变成了一个段。一旦创建，段是不可变的。为了防止Elasticsearch用微小的段填充磁盘，也为了防止它消耗大量的资源(inode、文件句柄等)，它不时合并段。这些合并操作有效地将两个或多个段的内容重新索引为一个更大的段。这在索引新文档的索引中不断发生。(对最终用户来说，它几乎是透明的，但对监视APIs可以显示一些细节。来说却是透明的)。

快照

如前所述，快照在段级捕获。这意味着增量不是在文档级别，而是自上次快照以来更改的段。假设快照将片段a1、a2和a3捕获到snapshot1中。几分钟后，这些段被合并到b1中。当拍摄下一次快照时，段a1、a2和a3不再存在，但b1存在，因此，在snapshot1和snapshot2中的段b1中都存在相同的文档，这些文档位于分段a1、a2和a3中。这种看似不必要的重复数据的理由是，快照必须能够准确地恢复到某个时间点，直到各个片段。

增量还意味着要管理的所有段必须与存储库中的所有段进行比较，以确保不发生片段的重复。--这就是为什么拍摄快照所需的时间随着存储库中快照的数量而增加的原因。

磁盘I/O的增加几乎可以肯定，这就是为什么索引和删除操作在快照操作期间超时。这一效果将随着要检查的段数的增加而恶化，正如您自己的请求在这里清楚显示的那样。

一个潜在的解决方案:多层快照存储库。

如果您有时间序列数据(如日志数据或度量数据)，这种方法可以很好地工作。这种方法意味着每小时的快照，但也添加了另一层的每日快照，也许在一个完全不同的存储库中。例如，您可能只保留每小时的快照，直到每天的索引被优化为每个碎片的1或2个段，然后被管理到它们自己的存储库中。这意味着每小时的快照只需要保存48-72小时。使用这种方法，您需要担心的片段将更少，还原将变得更加流线型，需要还原的文件/段将更少。

您仍然可以对非时间序列数据使用这种方法，但在获取下一层快照之前，它会失去合并段的一些好处。对于集群的性能而言，这仍然会导致在检查之间减少存储库中的片段，这是最终目标。

Answer 2

我读了不少这篇文章。我认为快照创建需要花费大量时间，因为ElasticSearch需要分析已经存在的快照，然后只将新数据复制到快照存储库。删除旧快照应该会有所帮助。另外，删除旧快照只会删除其他快照不使用的片段，因此不会丢失数据。

这也是github上的一个公开话题：https://github.com/elastic/elasticsearch/issues/8958

在查看了我们的存储库之后，我发现2K+快照可以追溯到2015年8月25日。只保留一个月的快照就足够了。