如何验证失败的 ElasticSearch 恢复？

Posted 2023-03-17

【中文标题】如何验证失败的 ElasticSearch 恢复？

【英文标题】：How can I validate a botched ElasticSearch recovery?

【发布时间】：2021-12-15 10:16:34

【问题描述】：

在较旧的生产节点上，我正在运行 ElasticSearch 6.8.0。我需要将索引从更旧的节点迁移到我们大纲的一部分以获取最新信息。这些节点是隔离的——不复制。为方便起见，我一直在小批量进行快照和恢复，但在项目快结束时，我认为我咬掉的东西超出了节点的承受能力。在恢复大型多索引快照（500GB！）期间，节点出现内存限制问题并出现故障。我曾担心过最坏的情况，但为了恢复，我将 RAM 加倍并将 VM 重新联机。令我惊讶的是，恢复似乎已经完成 - 所有索引和分片都显示 100%！所有索引的统计信息在源节点和被迁移到的节点上都匹配，这看起来很有希望，但我在我们领域的经验让我无法获得任何温暖和模糊的感觉。

我的问题：这是 ES 所期望的 - 从某些标准来看是奇迹般的恢复？有什么万无一失的验证方法吗？我应该对状态感到满意并继续，还是应该关闭作为“失败”快照恢复的一部分的索引并再次运行恢复？

很明显，我不是 ElasticSearch 大师 - 这项技术落在我的腿上，所以我边走边学。

谢谢大家！

【参考方案1】：

通常我会删除这个问题，但在这种情况下，我觉得回答我自己的问题可能对其他人有帮助 - 我真的希望这是因为删除问题并不能完全帮助社区。希望有进一步的意见来丰富这个线程以供未来的搜索者使用。

在深入挖掘之后，我发现其中 2 个指数处于 RED 状态。

GET /_cat/indices\?v

经过几次尝试，我仍然无法恢复它们。尽管其余的索引都还好，但我宁愿不冒险，所以我使用开发控制台从 Kibana 的新节点上删除了失败快照中的所有索引。

DELETE Index_1,Index_2,Index_3

当前正在运行同一快照的新恢复。我现在假设服务器已为此进行了适当的规范，我不应该有任何进一步的问题。

POST /_snapshot/shared_repo/mig-oct30-21/_restore "indices": "*", "include_global_state": false, "ignore_unavailable": true