Elasticsearch重新索引竞争条件

Question

您好elasticsearch用户/专家，

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

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

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

我的问题是，使用此方法时，我不希望停机（因此用户仍应能够搜索文档），并且仍希望能够在进行重新索引编制过程时将文档注入到ElasticSearch中：

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

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

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

提前致谢！

Answer 1

道歉，如果它太冗长，但我的两分钱：

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

当从源到目标进行重新索引编制时，别名（仍然必须）仍指向source_index 。 对该索引的所有修改/更改均以独立的方式发生，并且这些更新/删除应立即生效。

假设source_index的状态从t变为t+1

如果您已在t将重新索引作业运行到dest_index ，它将仍然消耗t处source_index快照的数据。 您需要再次运行重新索引作业以获取source_index最新数据，即dest_index位于t+1数据。

从source_index和从source_index到destination_index的接收都是独立的事务/进程。

重新索引作业永远不会始终保证source_index和dest_index之间的一致性。

如果在旧索引中修改了文档，则在重新索引索引（映射到新索引）之后，在重新索引过程运行的同时，ElasticSearch如何确保在新索引中也考虑到此修改？

在新索引中将不会考虑该索引，因为重新索引将利用时间t的source_index快照。

您将需要再次执行重新索引。 对于这种通用方法，将需要一个调度程序，该调度程序每隔几个小时保持运行一次索引编制过程。

您可以每隔几分钟（如果您使用调度程序）或实时（如果您使用任何基于事件的方法）在source_index进行更新/删除。

但是，对于完全索引（从source_index到dest_index ），将其安排为一天一次或两次，因为这是一个昂贵的过程。

（类似于2。）如果在旧索引中删除了记录，则在重新索引（映射到新索引）之后，在重新索引过程运行时，ElasticSearch将如何确保在新索引中也考虑到此删除指数？

同样，您需要运行一个新的作业/重新索引过程。

版本类型：外部

dest_index在dest_index编制索引期间您可以做的一件有趣的事情是，利用version_type:external来确保只有source_index已更新/缺失的文档才能在dest_index重新编制索引

您可以参考此链接以获取更多有关此的信息

POST _reindex
{
  "source": {
    "index": "source_index"
  },
  "dest": {
    "index": "dest_index",
    "version_type": "external"
  }
}