Elasticsearch：在不停机的情况下优化 Elasticsearch Reindex

实现零停机、高效率和成功迁移更新的指南。更多阅读：Elasticsearch：如何轻松安全地对实时 Elasticsearch 索引 reindex 你的数据。

在使用 Elasticsearch 的时候，总会有需要修改索引映射的时候，遇到这种情况，我们只能做 _reindex。事实上，这是一项相当昂贵的操作，因为根据数据量和分片数量，完成索引的完整复制可能需要长达几个小时的时间。

花费的时间并不是一个大问题，但更严重的是，它会影响生产环境的性能甚至功能。

相信大家都明白，数据迁移会消耗大量的硬盘资源，肯定会影响性能，但是功能呢？

我们以常规的 _reindex 为例。假设我们在索引上创建了一个别名。如果我们没有别名，我们就有大麻烦了。

常规 _reindex 过程分为两个步骤。

调用 _reindex 命令开始数据迁移。
数据迁移完成后，调用 _aliases 命令进行新旧索引切换。

步骤 2 之后，新索引正式运行，并将负责所有读写请求。然而，这只是一个完美的理想场景，事实上，事情不会那样发展。

下面是一个正常的场景。

实际上，在数据迁移期间或者切换别名之前，客户端会不断向原来的索引写入数据，而这些新的变化并不会迁移到新的索引中，从而导致数据不一致。

对于客户端来说，感觉是更改别名后，刚才所做的所有更改都会消失。此外，正如我刚才提到的，一个大的索引迁移可能需要几个小时，所以客户的感受一定是显而易见的。

那么该怎么办？

Reindex 的正确流程

上述流程对原始流程进行了两处更改。

_reindex 必须使用外部类型（external type）。
切换别名后再次需要 _reindex。

我们来解释一下外部类型的概念。

默认情况下，_reindex 是内部的，这种数据迁移是通过使用原始索引覆盖新索引来完成的，并删除文档的 _version，因此新索引中的所有文档重新开始。

如果使用外部类型，则数据迁移时文档的 _version 会被带入新索引，那么如果新旧索引的 _id 冲突，则会比较 _version。只有当原始文档的版本大于目标文档时才会被覆盖。

有点抽象？让我们举个例子。

假设原始索引有一个如下所示的文档，Elasticsearch 元数据位于下划线开头。

PUT test/_doc/1
{
  "data": "Hello Elastic"
}

{
    "_id": "1",
    "_version": 1,
    "data": "Hello Elastic"
}

我们再次运行上面的命令一次以使得它的版本号码变为 2：

假如我们使用如下的命令来进行 reindex：

POST _reindex
{
  "source": {
    "index": "test"
  },
  "dest": {
    "index": "test_reindexed"
  }
}

我们查看 test_reindexed 的内容：

GET test_reindexed/_doc/1

从上面的输出中，我们可以看出来无论之前的 version 号码是多少，在 reindex 之后，它的版本在新的索引中是 1，也即回到最初的版本。

上面的命令是 reindex 在默认时的表现。它相当于如下的命令格式：

POST _reindex
{
  "source": {
    "index": "test"
  },
  "dest": {
    "index": "test_reindexed",
    "version_type": "internal"
  }
}

在进行迁移的时候，我们可以把 version_type 设置为 external。那么它的命令格式是这样的：

DELETE test_reindexed

POST _reindex
{
  "source": {
    "index": "test"
  },
  "dest": {
    "index": "test_reindexed",
    "version_type": "external"
  }
}

运行完上面的命令后，我们可以查看 test_reindexd 里的数据：

GET test_reindexed/_doc/1

从上面的结果中，我们可以看出来，在新的索引中，它的 version 不再是之前 version_type 为 internal 时的情况。它的版本号现在是 2，而不是之前的 1。

当我们进行外部数据迁移时，_version: 2 也会被写入到新索引中。如果有人在数据迁移期间将原始文档更改为 Hello Search，那么完整的文档将如下所示。

PUT test/_doc/1
{
  "data": "Hello Search"
}

那么，ID 为 1 的文档的版本会变为 3.

{
    "_id": "1",
    "_version": 3,
    "data": "Hello Search"
}

重做 _reindex 将发现 3 > 3，因此它将被 Hello Search 覆盖。

我们再次重新进行 reindex，我们会发现由于 _version 的值变为 3，它是大于 test_reindexed 索引中的版本号码 2：

POST _reindex
{
  "source": {
    "index": "test"
  },
  "dest": {
    "index": "test_reindexed",
    "version_type": "external"
  }
}

我们再次查看最新的文档的值：

从上面的过程中，我们可以看出来：如果在迁移的过程中，或者我们再次运行 reindex，如果 test 中的值有变化，那么再次运行 reindex 后，它的值也会被更新到新的索引中。

那么，如果第二个 _reindex 有人修改了新索引中的文档怎么办？例如，如果有人在新索引中将 Hello Elatic 更改为 Hello Elasticsearch，是否会被旧值覆盖？整个过程如下所示。

答案是否定的，因为原始版本必须大于要覆盖的新版本才可以覆盖。

我们可以做如下的练习：

我们把 test_reindexed 中的文档的值修改为 Hello Elasticsearch：

PUT test_reindexed/_doc/1
{
  "data": "Hello Elasticsearch"
}

我们可以通过如下命令来查看它的值：

GET test_reindexed/_doc/1

我们再次确认 test 中的版本号码：

GET test/_doc/1

我们可以看到它们的版本号码是一致的。我们运行如下的 reindex：

POST _reindex
{
  "source": {
    "index": "test"
  },
  "dest": {
    "index": "test_reindexed",
    "version_type": "external"
  }
}

很显然，由于 test 文档中版本号要低于 test_reindexed 中的版本号，那么我们的文档不会被更新。

还有一个问题。

虽然我们会进行第二次 _reindex 来修补数据，但是如果修补时间很长，对于用户来说仍然会不一致。比如，在我们第一次的时候有多次更新，从而使得 test 中的 version 号码比较高。在切换之后，在 test_reindexed 中的文档更新过一次。那么在第二次 reindex 的过程中极有可能把 test 中的文档覆盖最新的数据中，从而造成数据的丢失。

有两种方法可以缩短重新索引时间。

尽可能减少第一次 _reindex 的时间。
提前过滤补丁数据。

关于第一点，_reindex 过程是由 Elasticsearch 控制的，我们还能做些什么来提高效率呢？嘿，有。

我们可以修改新索引的设置，以尽量减少数据迁移过程中的 IO 开销。

refresh_interval = -1
number_of_replicas = 0

这非常简单。首先，关闭 refresh_interval 的目的是让数据迁移期间只专注于写入 Translog，而不是在 Lucene 上花费额外的磁盘 IO。

其次，关闭 number_of_replicas 可以减少集群必须处理的额外数据复制开销。

另一方面，除了减少第一次 _reindex 的时间之外，还可以通过一些数据过滤来减少第二次 _reindex 的数据量。

例如，在 _reindex 期间引入数据的最后更新时间是一种可能的解决方案。假设每个文档都有一个 updated_at 字段，那么在 _reindex 的查询中添加以下条件就会有效。

{
    "range": {
        "updated_at": { "gte": "now-1d"}
    }
}

结论

基于上述细节，让我们列出重建索引的理想流程。

创建目标索引。
更新目标索引的设置。 (refresh_interval = -1 且 number_of_replicas = 0)
使用外部类型进行 _reindex。
将别名从原始索引切换到目标索引。
使用外部类型再次执行 _reindex，最好进行额外的过滤。
再次更新目标索引设置。（refresh_interval = null 且 number_of_replicas = null）

根据官方文档，设置为 null 可以恢复原来的设置。

因为 _reindex 是不可避免的，所以了解如何在不停机的情况下执行 _reindex 很重要。

事实上，利用 Elasticsearch 的流式索引，有更优雅的方法来完成它。然而，流式索引的用例有很多限制，因此在实践中更常见的是使用常规索引。

本文提供了一个完整的过程来尽可能快地执行 _reindex 并最大限度地减少数据不一致的时间。然而，所有这些都假设别名已正确创建，如果没有正确创建，则需要更多额外的步骤。我觉得缺少别名已经违反了 Elasticsearch 的最佳实践，因此本文不会专门讨论这种情况。