Question

您好弹性搜索用户/专家

我在用Elasticsearch的reindex api理解竞争条件问题时遇到了一些麻烦，想听听是否有人找到了解决方案。

我搜索了很多地方，找不到任何明确的解决方案（大多数解决方案可追溯到reindex api之前）。

您可能知道，（现在）重新编制文档索引的标准方法（例如，在更改映射之后）是使用别名。假设别名指向“ old_index”。然后，我们使用新的映射关系创建一个名为“ new_index”的新索引，我们调用reindex api将文档从“ old_index”重新索引为“ new_index”，然后将别名切换为指向new_index（并删除指向old_index的别名指针））。看来，这是重新编制索引的标准方式，这也是我在最近访问的几乎所有网站上都看到的内容。

使用此方法时，我的问题如下，虽然我不希望停机（因此用户仍应能够搜索文档），并且在重新索引过程中我仍希望能够将文档注入到ElasticSearch中正在发生：

如果在重新编制索引的过程中仍会接收文档（这可能会花费很多时间），那么重新编制索引的过程将如何确保将文档提取到旧索引中（以便能够进行搜索）虽然重新编制索引的过程正常进行），但仍然可以正确地重新编制索引到新索引吗？
如果在旧索引中修改了文档，则在重新建立索引（映射到新索引）之后，在重新索引过程运行的同时，ElasticSearch如何确保在新索引中也考虑到此修改？ / li>
（类似于2。）如果一条记录在旧索引中被删除，则在重新建立索引（映射到新索引）之后，在重新索引过程运行时，ElasticSearch将如何确保也考虑到此删除在新索引中？

基本上在无法为文档建立索引错误的情况下，如何能够确保重新索引不会出现上述任何问题？

有人有什么主意吗？而且，如果没有没有停机的解决方案，那么在这种情况下，我们将如何以最少的停机时间进行处理？

谢谢！

Answer 1

道歉，如果太冗长，可是我的两分钱：

如果在重新索引过程中仍将文档送入工作（可能会花费很多时间），重新编制索引的过程可确保将文档提取到旧索引（能够在重新索引过程中进行搜索工作），但仍然可以正确地重新索引到新索引？

当从源到目标进行重新索引编制时，别名仍（并且必须是）仍指向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

Elasticsearch重新索引竞争条件

1 个答案: