我想以零停机时间进行替换和索引,如中所述ES 文档 https://www.elastic.co/guide/en/elasticsearch/guide/current/index-aliases.html.
我这样做是通过:
- 创建一个新索引
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
}
- 之后,只有当交换有效时,我们才会删除与此别名关联的现在未使用的索引。
整个操作每隔几分钟定期发生一次。与所描述的操作类似的操作可能会同时在集群中的其他别名/索引上发生。该错误每隔几个小时随机发生一次。
这些操作是否有相互干扰的原因?到底是怎么回事?
EDIT:最后澄清了 DELETE 步骤。
这在本地环境中很难重现,因为它似乎只发生在高度并发的场景中。然而...正如 @Eirini Graonidou 在评论中指出的,这确实看起来像 ES 错误,PR 23153 中已解决 https://github.com/elastic/elasticsearch/pull/23153
来自拉取请求(强调我的):
这要么导致发送错误请求时的令人困惑的响应到
Elasticsearch(如果名为“bad-request”的索引不存在,那么它
产生索引未找到异常,否则以
名为“bad-request”的索引的索引设置)。
这并不能解释“错误请求”的情况,但绝对可以解释为什么错误消息没有意义。
更重要的是:升级elasticsearch解决这个问题
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)