正在拍摄快照时，elasticsearch 在 delete/create 期间请求超时
Request timedout during delete/create on elasticsearch while snapshot is being taken
我正在使用 nodejs 连接到 elasticsearch 并使用 curator 每小时拍摄快照。
当 snapshop 操作为 运行 时，许多 create/delete 请求在等待 30 秒后超时。更严重的问题是，在删除过程中甚至请求超时，客户端假设删除失败但成功了，可能是在超时之后。这导致数据损坏。
我也注意到拍摄快照的时间不断线性增加。 6 个月后现在需要 4 分钟，即使它声称备份是增量过程。
我已经用下面的命令做了备份
/usr/local/bin/curator snapshot --repository mt_es_backup indices --all-indices >> /vol/es/es_backup.log 2>&1
谢谢
Curator 不太可能是这里的问题（披露：我是 Elasticsearch Curator 的作者）。
存储库中的快照数量会影响快照持续时间，甚至会影响快照期间的集群性能。 Elasticsearch 中的快照 在文件级别是 增量的，但有问题的文件称为段。
段数
Elasticsearch 中最基本的存储单元是段。当文档进入 Elasticsearch 进行索引时，它们会被处理到一个缓冲区中。当该缓冲区被刷新时，它的内容就变成了一个段。一旦创建，段是不可变的。为了防止 Elasticsearch 用小段填满您的磁盘， 并且 防止它消耗大量资源（索引节点、文件句柄等），它 merges segments from time to time. These merge operations are effectively re-indexing the contents of two or more segments into one larger segment. This happens continuously in indices that are indexing new documents. (It is nearly transparent to end users, but monitoring APIs can show some detail) .
快照
如前所述，快照在段级别捕获。这意味着增量不在文档级别，而是 自上次快照以来更改的段。 假设快照捕获段 a1， a2，a3 到 snapshot1。然后几分钟后，这些片段被合并成 b1。拍摄下一个快照时，段 a1、a2 和 a3 不再存在，但 b1 确实如此，因此段 a1、a2 和 [=33= 中的相同文档也是如此]a3 存在于 snapshot1 和 snapshot2 中的段 b1 中。这种看似不必要的数据重复的原因是快照必须能够准确恢复到某个时间点，具体到个人段。
增量还意味着所有要拍摄快照的段都必须与存储库中的所有段进行比较，以确保不会发生段重复。 这就是拍摄快照所需的持续时间随着存储库中快照数量的增加而增加的原因。
段检查增加的磁盘 I/O 几乎可以肯定是索引和删除操作在快照操作期间超时的原因。随着要检查的段数的增加，这种效果会恶化，正如您在此处的要求清楚地表明的那样。
潜在解决方案：多层快照存储库。
如果您有时间序列数据（如日志或指标数据），这种方法很有效。这种方法意味着每小时快照，但也会添加另一层 每日 快照，可能在一个完全不同的存储库中。例如，您可能只保留每小时快照，直到每日索引已优化为每个分片 1 或 2 个段，然后快照到它们自己的存储库中。这意味着每小时快照只需要保留 48 - 72 小时。使用这种方法，您需要担心的段更少，并且恢复将变得更加精简，需要恢复的 files/segments 更少。
您可以仍然对非时间序列数据使用这种方法，但它失去了在获取下一层快照之前合并段的一些好处。它仍然会导致检查之间的存储库中的段更少，这是这里的最终目标，以提高集群的性能。
我对此做了很多阅读。我相信创建快照会花费很多时间，因为 ElasticSearch 需要分析已经存在的快照，然后只将新数据复制到快照存储库。删除旧快照应该有所帮助。另外，删除旧快照只会删除其他快照未使用的段，因此不会丢失数据。
这也是 github 上的未决问题：https://github.com/elastic/elasticsearch/issues/8958
查看我们的存储库后，我发现那里有 2000 多个快照，可追溯到 2015 年 8 月 25 日。只保留一个月的快照就足够了。
我正在使用 nodejs 连接到 elasticsearch 并使用 curator 每小时拍摄快照。
当 snapshop 操作为 运行 时，许多 create/delete 请求在等待 30 秒后超时。更严重的问题是，在删除过程中甚至请求超时，客户端假设删除失败但成功了，可能是在超时之后。这导致数据损坏。
我也注意到拍摄快照的时间不断线性增加。 6 个月后现在需要 4 分钟，即使它声称备份是增量过程。
我已经用下面的命令做了备份
/usr/local/bin/curator snapshot --repository mt_es_backup indices --all-indices >> /vol/es/es_backup.log 2>&1
谢谢
Curator 不太可能是这里的问题（披露：我是 Elasticsearch Curator 的作者）。
存储库中的快照数量会影响快照持续时间，甚至会影响快照期间的集群性能。 Elasticsearch 中的快照 在文件级别是 增量的，但有问题的文件称为段。
段数
Elasticsearch 中最基本的存储单元是段。当文档进入 Elasticsearch 进行索引时，它们会被处理到一个缓冲区中。当该缓冲区被刷新时，它的内容就变成了一个段。一旦创建，段是不可变的。为了防止 Elasticsearch 用小段填满您的磁盘， 并且 防止它消耗大量资源（索引节点、文件句柄等），它 merges segments from time to time. These merge operations are effectively re-indexing the contents of two or more segments into one larger segment. This happens continuously in indices that are indexing new documents. (It is nearly transparent to end users, but monitoring APIs can show some detail) .
快照
如前所述，快照在段级别捕获。这意味着增量不在文档级别，而是 自上次快照以来更改的段。 假设快照捕获段 a1， a2，a3 到 snapshot1。然后几分钟后，这些片段被合并成 b1。拍摄下一个快照时，段 a1、a2 和 a3 不再存在，但 b1 确实如此，因此段 a1、a2 和 [=33= 中的相同文档也是如此]a3 存在于 snapshot1 和 snapshot2 中的段 b1 中。这种看似不必要的数据重复的原因是快照必须能够准确恢复到某个时间点，具体到个人段。
增量还意味着所有要拍摄快照的段都必须与存储库中的所有段进行比较，以确保不会发生段重复。 这就是拍摄快照所需的持续时间随着存储库中快照数量的增加而增加的原因。
段检查增加的磁盘 I/O 几乎可以肯定是索引和删除操作在快照操作期间超时的原因。随着要检查的段数的增加，这种效果会恶化，正如您在此处的要求清楚地表明的那样。
潜在解决方案：多层快照存储库。
如果您有时间序列数据（如日志或指标数据），这种方法很有效。这种方法意味着每小时快照，但也会添加另一层 每日 快照，可能在一个完全不同的存储库中。例如，您可能只保留每小时快照，直到每日索引已优化为每个分片 1 或 2 个段，然后快照到它们自己的存储库中。这意味着每小时快照只需要保留 48 - 72 小时。使用这种方法，您需要担心的段更少，并且恢复将变得更加精简，需要恢复的 files/segments 更少。
您可以仍然对非时间序列数据使用这种方法，但它失去了在获取下一层快照之前合并段的一些好处。它仍然会导致检查之间的存储库中的段更少，这是这里的最终目标，以提高集群的性能。
我对此做了很多阅读。我相信创建快照会花费很多时间，因为 ElasticSearch 需要分析已经存在的快照，然后只将新数据复制到快照存储库。删除旧快照应该有所帮助。另外，删除旧快照只会删除其他快照未使用的段，因此不会丢失数据。
这也是 github 上的未决问题：https://github.com/elastic/elasticsearch/issues/8958
查看我们的存储库后，我发现那里有 2000 多个快照，可追溯到 2015 年 8 月 25 日。只保留一个月的快照就足够了。