原子别名交换在完全不相关的索引上失败并带有index_not_found_exception

Question

我想用零停机时间替换和索引,如ES文档中所述.

我这样做是这样的:

• my_index_v2使用新数据创建新索引
• 刷新新索引
• 然后通过执行以下请求在原子操作中交换它们:

POST /_aliases

{
    "actions": [
        { "remove": { "index": "*", "alias": "my_index" }},
        { "add":    { "index": "my_index_v2", "alias": "my_index" }}
    ]
}

这可以按预期工作,除非它随机响应404响应.错误消息是:

{
   "error": {
      "root_cause": ... (same)
      "type": "index_not_found_exception",
      "reason": "no such index",
      "resource.type": "index_or_alias",
      "resource.id": "my_unrelated_index_v13",
      "index": "my_unrelated_index_v13"
   },
   "status": 404
}

• 之后,只有当交换工作时,我们才会删除与此关联的现在未使用的索引,并且只删除此别名.

整个操作每隔几分钟就会定期发生.与所描述的操作类似的操作可能在群集中同时发生在其他别名/索引上.每隔几个小时就会随机发生错误.

有没有理由说这些操作会相互干扰？到底是怎么回事？

编辑:最后阐明了DELETE步骤.

Answer 1

这很难在本地环境中重现，因为它似乎只发生在高度并发的场景中。然而...正如 @Eirini Graonidou 在评论中指出的，这确实看起来像一个 ES 错误，已在 PR 23153 中解决

来自拉取请求（强调我的）：

当错误请求发送到 Elasticsearch 时，这会导致令人费解的响应（如果名为“bad-request”的索引不存在，则会产生索引未找到异常，否则会使用名为“bad-request”的索引的索引设置进行响应） ”）。

这并不能解释“错误请求”的情况，但绝对可以解释为什么错误消息没有意义。

更重要的是：升级elasticsearch解决了这个问题