您好弹性搜索用户/专家
我在用Elasticsearch的reindex api理解竞争条件问题时遇到了一些麻烦，想听听是否有人找到了解决方案。
我搜索了很多地方，找不到任何明确的解决方案（大多数解决方案可追溯到reindex api之前）。
您可能知道，（现在）重新编制文档索引的标准方法（例如，在更改映射之后）是使用别名。 假设别名指向“ old_index”。然后，我们使用新的映射关系创建一个名为“ new_index”的新索引，我们调用reindex api将文档从“ old_index”重新索引为“ new_index”，然后将别名切换为指向new_index（并删除指向old_index的别名指针） ）。看来，这是重新编制索引的标准方式，这也是我在最近访问的几乎所有网站上都看到的内容。
使用此方法时，我的问题如下，虽然我不希望停机（因此用户仍应能够搜索文档），并且在重新索引过程中我仍希望能够将文档注入到ElasticSearch中正在发生：
基本上在无法为文档建立索引错误的情况下，如何能够确保重新索引不会出现上述任何问题？
有人有什么主意吗？而且，如果没有没有停机的解决方案，那么在这种情况下，我们将如何以最少的停机时间进行处理？
谢谢！
答案 0 :(得分：2)
道歉，如果太冗长，可是我的两分钱：
如果在重新索引过程中仍将文档送入 工作（可能会花费很多时间）， 重新编制索引的过程可确保将文档提取到 旧索引（能够在重新索引过程中进行搜索 工作），但仍然可以正确地重新索引到新索引？
当从源到目标进行重新索引编制时，别名仍（并且必须是）仍指向source_index。对该索引的所有修改/更改均以独立的方式发生，并且这些更新/删除应立即生效。
让我们说source_index的状态从t变为t+1
如果您已经在t到dest_index上执行了重新索引编制作业，它将仍然消耗source_index上t的快照数据。您需要再次运行重新索引作业，以获取source_index的最新数据，即t+1中dest_index的数据。
在source_index处的摄取和从source_index到destination_index的摄取都是独立的事务/过程。
重新索引作业永远不会始终保证source_index和dest_index之间的一致性。
如果文档在旧索引中进行了修改，则在修改之后 重新索引（映射到新索引），而重新索引过程是 工作，ElasticSearch如何确保此修改也 在新索引中考虑了？
在新索引中将不会考虑该索引，因为重新索引将使用source_index时间的t快照。
您将需要再次执行重新索引编制。对于这种通用方法，将需要一个调度程序，该调度程序每隔几个小时保持运行一次索引编制过程。
您可以每隔几分钟（如果您使用调度程序）或实时（如果您使用任何基于事件的方法）在source_index上进行更新/删除。
但是，要进行完全索引编制（从source_index到dest_index），应该安排它一天一次或两次，因为这是一个昂贵的过程。
（类似于2。）如果一条记录在旧索引中被删除，则在 重新索引（映射到新索引），而重新索引过程 正在运行，ElasticSearch如何确保此删除操作也 在新索引中考虑了？
同样，您需要运行一个新的作业/重新索引过程。
版本类型：外部
作为一个补充说明，重新编制索引期间可以做的一件有趣的事情是，利用 version_type:external 可以确保仅{{1}中更新/丢失的文档}将在source_index
您可以参考此LINK以获得更多信息
dest_index