我们一直使用此link作为参考,以适应索引中字段映射的任何更改,并且停机时间为零。
问题: 考虑到上述链接中采用的相同示例,当我们重新索引数据时 使用_reindex API将my_index_v1发送到my_index_v2。 ElasticSearch是否保证my_index_v1中发生的任何并发更新都会使其成为my_index_v2?
例如,在api重新编制索引到my_index_v2之前或之后,文档可能会在my_index_v1中更新。
最终,我们只需要确保虽然我们不希望任何映射更改的停机时间(因此使用别名和ES的其他很酷的东西做_reindex),我们也希望确保没有任何添加/更新错过了这个巨大的重新索引正在进行中,因为我们正在谈论重新索引> 50GB数据。
谢谢,
和Sandeep
答案 0 :(得分:1)
看起来就像基于源索引的快照一样。
对我来说,他们无法合理地尊重在流程中间发生的变化。您可以避免在搜索方面停机,但我认为您需要在此过程中暂停索引端的更新。
您可以做的事情是跟踪上次修改文档的索引。然后,一旦完成索引并切换别名,就可以在旧索引中查询中间更改的内容。将这些更改传播到新索引,您将获得最终的一致性。
答案 1 :(得分:1)
The reindex api will not consider the changes made after the process has started.. One thing you can do is once you are done reindexing process.You can again start process with version_type:external. This will cause only documents from source index to destination index that have different version and are not present
Here is the example
POST _reindex
{
"source": {
"index": "twitter"
},
"dest": {
"index": "new_twitter",
"version_type": "external"
}
}
Setting version_type to external will cause Elasticsearch to preserve the version from the source, create any documents that are missing, and update any documents that have an older version in the destination index than they do in the source index:
答案 2 :(得分:1)
解决此问题的一种方法是使用两个别名而不是一个。一种用于查询(简称为 read_alias ),另一种用于索引编制( write_alias )。我们可以编写代码,以便所有索引都通过 write_alias 进行,所有查询都通过 read_alias 进行。让我们考虑三个时间段:
重建之前
read_alias :指向 current_index
所有查询均返回当前数据。
所有修改都放在 current_index 中。
重建期间
read_alias :指向 current_index
由于搜索代码使用 read_alias ,因此所有查询都将继续获取重建之前的数据。
所有行(包括已修改的行)都被索引到 new_index 中,因为重建循环和数据库触发器均使用 write_alias 。
重建后
read_alias :指向 new_index
所有查询都返回新数据,包括在重建过程中所做的修改。
所有修改都放入 new_index 。
如果我们在重建进行时(即,别名指向不同的索引)使DB触发器代码的索引修改行同时进入两个索引,则甚至有可能在重建时从查询中获取修改后的数据。
使用自定义代码而不是依靠 _reindex API从源数据重建索引通常会更好,因为那样可以添加可能未存储在旧索引中的新字段
This article有更多详细信息。