我们一直使用此 link 作为参考，以适应索引中字段映射的任何变化，且停机时间为零。
问题： 考虑到上面链接中的相同示例，当我们重新索引来自的数据时 my_index_v1 到 my_index_v2 使用_reindex API。 ElasticSearch 是否保证 my_index_v1 中发生的任何并发更新肯定会到达 my_index_v2？
例如，文档可能会在通过 api 重新索引到 my_index_v2 之前或之后在 my_index_v1 中更新。
最终，我们只需要确保虽然我们不希望任何停机时间来进行任何映射更改（因此 _reindex 使用别名和 ES 的其他很酷的东西），但我们还希望确保没有任何添加/更新在这个巨大的重新索引正在进行时错过了，因为我们正在谈论重新索引 >50GB 的数据。
谢谢，
桑迪普
【问题讨论】：
标签： elasticsearch
reindex api 不会考虑进程启动后所做的更改。 您可以做的一件事是在完成重新索引过程后。您可以使用 version_type:external 再次启动该过程。 这将导致只有从源索引到目标索引的文档具有不同的版本并且不存在
这是一个例子
POST _reindex
{
"source": {
"index": "twitter"
},
"dest": {
"index": "new_twitter",
"version_type": "external"
}
}
将 version_type 设置为 external 将导致 Elasticsearch 保留源中的版本，创建任何丢失的文档，并更新目标索引中版本比源索引中的旧版本的任何文档：
【讨论】：
解决此问题的一种方法是使用两个别名而不是一个别名。一个用于查询（我们称之为 read_alias），一个用于索引（write_alias）。我们可以编写代码，以便所有索引都通过 write_alias 进行，所有查询都通过 read_alias 进行。让我们考虑三个时间段：
重建前
read_alias：指向current_index
所有查询都返回当前数据。
所有修改都进入 current_index。
重建期间
read_alias：指向current_index
由于搜索代码使用read_alias，所有查询都会继续获取重建前存在的数据。
所有行，包括修改的行，都被索引到 new_index，因为重建循环和 DB 触发器都使用 write_alias。
重建后
read_alias：指向 new_index
所有查询都返回新数据，包括重建期间所做的修改。
所有修改都进入 new_index。
如果我们在重建过程中让数据库触发器代码将修改后的行索引到两个索引中（即别名指向不同的索引），甚至应该可以在重建时从查询中获取修改后的数据。
使用自定义代码从源数据重建索引通常比依赖 _reindex API 更好，因为这样我们可以添加可能未存储在旧索引中的新字段.
This article 有更多详细信息。
【讨论】：
它看起来就像它基于源索引的快照所做的那样。
这向我表明，他们无法合理地尊重在流程中间发生的源更改。您可以避免搜索端的停机时间，但我认为您需要在此过程中暂停索引端的更新。
您可以做的事情是跟踪文档上次修改时间的索引。然后，一旦完成索引并切换别名，就可以查询旧索引以了解中间发生的变化。将这些更改传播到新索引，您将获得最终的一致性。
【讨论】：