我正在使用 nodejs 连接到 elasticsearch 并使用 curator 来拍摄每小时快照。
当 snapshop 操作运行时，许多创建/删除请求在等待 30 秒后超时。更严重的问题是，在删除期间，即使请求超时，客户端也认为删除失败但它成功了，可能是在发生超时之后。这导致数据损坏。
我还注意到拍摄快照的时间不断线性增加。6 个月后现在需要 4 分钟，即使它声称备份是增量过程。
我已使用以下命令进行备份
/usr/local/bin/curator snapshot --repository mt_es_backup indices --all-indices >> /vol/es/es_backup.log 2>&1
谢谢
我对此做了很多阅读。我相信创建快照需要花费很多时间，因为 ElasticSearch 需要分析已经存在的快照，然后只将新数据复制到快照存储库。删除旧快照应该会有所帮助。此外，删除旧快照只会删除其他快照未使用的段，因此不会丢失数据。
这也是 github 上的一个开放问题：https ://github.com/elastic/elasticsearch/issues/8958
查看我们的存储库后，我发现有 2K+ 的快照可以追溯到 2015 年 8 月 25 日。只保留一个月的快照就足够了。
Curator 不太可能是这里的问题（披露：我是 Elasticsearch Curator 的作者）。
存储库中的快照计数可能会影响快照持续时间，甚至会影响快照期间的集群性能。Elasticsearch 中的快照在文件级别是增量的，但有问题的文件称为段。
细分市场
Elasticsearch 中最基本的存储单元是一个段。当文档进入 Elasticsearch 进行索引时，它们会被处理到缓冲区中。当该缓冲区被刷新时，其内容成为一个段。一旦创建，一个段就是不可变的。为了防止 Elasticsearch 用微小的段填充您的磁盘，也为了防止它消耗大量资源（inode、文件句柄等），它会不时合并段。这些合并操作有效地将两个或多个段的内容重新索引到一个更大的段中。这在索引新文档的索引中不断发生。（它对最终用户几乎是透明的，但监控 API 可以显示一些细节）。
快照
如前所述，快照是在段级别捕获的。这意味着增量不是在文档级别，而是自上次快照以来已更改的段。 假设快照将分段a1、a2和a3捕获到snapshot1中。然后几分钟后，这些片段被合并到b1中。当拍摄下一个快照时，片段a1、a2和a3不再存在，但b1存在，因此片段a1、a2和a3中的相同文档存在于两个快照1中在快照2中的段b1中。这种看似不必要的数据重复的原因是快照必须能够准确地恢复到一个时间点，一直到各个段。
增量还意味着必须将要创建快照的所有段与存储库中的所有段进行比较，以确保不会发生段重复。 这就是为什么拍摄快照所需的持续时间会随着存储库中的快照数量而增加。
几乎可以肯定，段检查导致的磁盘 I/O 增加是索引和删除操作在快照操作期间超时的原因。随着要检查的段数的增加，这种效果会恶化，正如您自己的请求在这里清楚地表明的那样。
一个潜在的解决方案：多层快照存储库。
如果您有时间序列数据，例如日志或指标数据，这种方法很有效。这种方法意味着每小时快照，但也添加了另一层每日快照，可能在一个完全不同的存储库中。例如，您可能只保留每小时快照，直到每日索引优化到每个分片 1 或 2 个段，然后快照到它们自己的存储库中。这意味着每小时快照只需要保留 48 - 72 小时。使用这种方法，您需要担心的段更少，还原将变得更加流畅，需要还原的文件/段也更少。
您仍然可以将此方法用于非时间序列数据，但它失去了在获取下一层快照之前合并段的一些好处。它仍然会导致检查之间存储库中的段更少，这就是这里的最终目标，以提高集群的性能。