Elasticsearch专题精讲—— REST APIs —— Document APIs —— Reindex API

REST APIs —— Document APIs —— Reindex API

https://www.elastic.co/guide/en/elasticsearch/reference/8.8/docs-reindex.html#docs-reindex

Copies documents from a source to a destination.

将文档从源复制到目标。

The source can be any existing index, alias, or data stream. The destination must differ from the source. For example, you cannot reindex a data stream into itself.

源可以是任何现有的索引、别名或数据流。目标必须与源不同。例如，您不能将数据流重新索引到自身。

Reindex requires _source to be enabled for all documents in the source.

重新索引要求源中所有文档启用 _source。

The destination should be configured as wanted before calling _reindex. Reindex does not copy the settings from the source or its associated template.

在调用 _reindex 之前，应按照所需配置目标。重新索引不会复制源或其关联模板的设置。

The destination should be configured as wanted before calling _reindex. Reindex does not copy the settings from the source or its associated template.

必须提前配置映射、分片数量、副本等内容。

        curl -X POST "localhost:9200/_reindex?pretty" -H 'Content-Type: application/json' -d'
        {
          "source": {
            "index": "my-index-000001"
          },
          "dest": {
            "index": "my-new-index-000001"
          }
        }'

我理解意思是说： Reindex API 是 Elasticsearch 提供的一种用于将数据从源索引或别名重新索引到目标索引的接口。使用该接口，可以快速地将数据从一个索引迁移到另一个索引，或者在数据结构发生变化时，将数据从旧的索引重新索引到新的索引中。

在使用 Reindex API 进行重新索引之前，需要注意以下几点：

源可以是任何现有的索引、别名或数据流。目标必须不同于源，不能将数据流重新索引到它本身。
源中的所有文档都必须启用 _source。
在调用 _reindex 之前，应按照所需配置目标。重新索引不会复制源或其关联模板的设置。
必须提前配置映射、分片数量、副本等内容。

1、Request（请求）

https://www.elastic.co/guide/en/elasticsearch/reference/8.8/docs-reindex.html#docs-reindex-api-request

        POST /_reindex

        POST /_reindex

2、Prerequisites（先决条件）

https://www.elastic.co/guide/en/elasticsearch/reference/8.8/docs-reindex.html#docs-reindex-api-prereqs

If the Elasticsearch security features are enabled, you must have the following security privileges:

如果启用了 Elasticsearch 安全特性，您必须拥有以下安全特权:
源数据流、索引或别名的读取索引权限。
目标数据流、索引或索引别名的写入索引特权。

我理解意思是说：在 Elasticsearch 中使用默认安全插件的情况下，如何设置这两个权限将取决于你使用的是哪种身份验证方式。一般而言，有两种身份验证方式可以使用：基于角色的身份验证和本地用户身份验证。

对于基于角色的身份验证，你需要为你的角色授予源数据流、索引或别名的“读索引权限（read index privilege）”，以及目标数据流、索引或别名的“写索引权限（write index privilege）”。具体设置步骤请参考 Elasticsearch 的官方文档中有关“基于角色的访问控制（Role-based Access Control）”的部分。

对于本地用户身份验证，你需要为你的本地用户授予与角色所授予的权限相同的权限。与基于角色的身份验证不同，本地用户身份验证是在 Elasticsearch 集群中直接创建和存储用户凭证信息，因此它独立于外部身份验证提供程序（如 LDAP 或 Active Directory）。具体设置步骤请参考 Elasticsearch 的官方文档中有关“安全（Security）”的部分。

总之，无论你使用的是基于角色的身份验证还是本地用户身份验证，你都需要在 Elasticsearch 集群中为用户或角色分配相应的索引权限，才能在使用 _reindex API 进行文档重建操作时顺利执行。
要通过 Reindex API 请求自动创建一个数据流或索引，您必须具有目标数据流、索引或别名的 auto_configure、create_index 或 manage_index 权限。

我理解意思是说：如果您想要给用户或者角色添加 "auto_configure", "create_index" 或者 "manage index" 权限，您需要操作 Elasticsearch 的安全模块。具体步骤如下：

1、打开Elasticsearch的安全模块：在elasticsearch.yml配置文件中设置以下参数： xpack.security.enabled: true

2、创建一个用户或角色，例如，创建一个名为"test_user"的用户，命令如下：
```
POST /_security/user/test_user
                        {
                          "password" : "test_password",
                          "roles" : [ "auto_configure", "create_index", "manage" ]
                        }
```
3、授予自动配置、创建索引和管理索引权限：
```
PUT //_settings
                        {
                          "index": {
                            "auto_expand_replicas": "0-1",
                            "blocks": {
                              "read_only_allow_delete": "false"
                            }
                          }
                        }
                        
```
其中，是您想要设置权限的索引名称。在这个命令中，我们授予了该索引的写权限。通过上述操作，您就可以添加"auto_configure"、"create_index" 和 "manage index" 权限了。需要注意的是，添加权限前必须确保您使用的是至少能满足这些权限要求的 Elasticsearch 版本，并且您必须具有足够的管理员权限来进行上述操作。
如果从远程集群进行重新索引，则 source.remote.user 必须具有监视集群特权（https://www.elastic.co/guide/en/elasticsearch/reference/8.8/security-privileges.html#privileges-list-cluster）以及源数据流、索引或别名的读取索引权限。

我理解意思是说：在使用 _reindex API 从远程集群进行索引重建时，你需要在 Elasticsearch 的配置文件 elasticsearch.yml 中明确地指定允许访问远程集群的白名单。具体来说，需要设置 reindex.remote.whitelist 参数来包含远程集群的主机地址或 IP 地址，否则 Elasticsearch 将不允许你连接远程集群进行索引重建操作。

例如，你可以在 elasticsearch.yml 中如下配置：reindex.remote.whitelist: 192.168.0.1:9200

上述配置指示 Elasticsearch 允许从主机地址为 192.168.0.1 且端口为 9200 的远程集群进行索引重建操作。如果你有多个远程集群需要连接，你可以使用逗号分隔多个地址： reindex.remote.whitelist: 192.168.0.1:9200,192.168.0.2:9200

需要注意的是，如果你的 Elasticsearch 版本较旧，可能会使用 reindex.http.ssl.whitelist 或 reindex.ssl.verification_mode 等参数来控制远程集群的访问权限，请根据实际情况进行相应的配置。同时需要确保远程集群的访问权限设置正确，否则将会导致索引重建操作失败。
If reindexing from a remote cluster, you must explicitly allow the remote host in the reindex.remote.whitelist setting of elasticsearch.yml. See Reindex from remote.

如果从远程集群进行重新索引，则必须在 elasticsearch.yml 中的 reindex.remote.whitelist 设置中显式允许远程主机。请参见远程重索引（https://www.elastic.co/guide/en/elasticsearch/reference/8.8/docs-reindex.html#reindex-from-remote）。

Automatic data stream creation requires a matching index template with data stream enabled. See Set up a data stream.

自动数据流创建需要启用数据流的匹配索引模板。请参见设置数据流。（https://www.elastic.co/guide/en/elasticsearch/reference/8.8/set-up-a-data-stream.html）

3、Description（描述）

https://www.elastic.co/guide/en/elasticsearch/reference/8.8/docs-update-by-query.html#docs-update-by-query-api-desc

Extracts the document source from the source index and indexes the documents into the destination index. You can copy all documents to the destination index, or reindex a subset of the documents.

从源索引中提取文档源，并将文档索引到目标索引中。您可以将所有文档复制到目标索引，或者重新索引文档的一个子集。

Just like _update_by_query, _reindex gets a snapshot of the source but its destination must be different so version conflicts are unlikely. The dest element can be configured like the index API to control optimistic concurrency control. Omitting version_type or setting it to internal causes Elasticsearch to blindly dump documents into the destination, overwriting any that happen to have the same ID.

就像 _update_by_query API 一样，_reindex API 也可以获取源的快照，但其目标必须不同，因此版本冲突的可能性较小。可以像索引 API 一样对 dest 元素进行配置以控制乐观并发控制。如果省略 version_type 参数或将其设置为 internal，则 Elasticsearch 会盲目地将文档转储到目标中，覆盖任何具有相同 ID 的文档。

Setting version_type to external causes Elasticsearch to preserve the version from the source, create any documents that are missing, and update any documents that have an older version in the destination than they do in the source.

将 version_type 设置为外部版本会导致 Elasticsearch 从源代码保留版本，创建丢失的所有文档，并更新目标文档中的旧版本比源代码中的旧版本更新的所有文档。

Setting op_type to create causes _reindex to only create missing documents in the destination. All existing documents will cause a version conflict.

将 op_type 设置为 create 会导致 _reindex 只在目标索引中创建缺失的文档。所有已存在的文档都会引起版本冲突。

Because data streams are append-only, any reindex request to a destination data stream must have an op_type of`create`. A reindex can only add new documents to a destination data stream. It cannot update existing documents in a destination data stream.

由于数据流是仅追加的，因此到目标数据流的任何重新索引请求必须具有 create 的操作类型。重新索引只能向目标数据流添加新文档，而无法更新目标数据流中的现有文档。

By default, version conflicts abort the _reindex process. To continue reindexing if there are conflicts, set the "conflicts" request body parameter to proceed. In this case, the response includes a count of the version conflicts that were encountered. Note that the handling of other error types is unaffected by the "conflicts" parameter. Additionally, if you opt to count version conflicts the operation could attempt to reindex more documents from the source than max_docs until it has successfully indexed max_docs documents into the target, or it has gone through every document in the source query.

默认情况下，版本冲突会中止 _reindex 过程。如果存在冲突，要继续重新索引，请将请求体参数 "conflicts" 设置为 proceed。在这种情况下，响应将包括遇到的版本冲突的计数。请注意，其他错误类型的处理不受 "conflicts" 参数的影响。此外，如果选择计算版本冲突，则该操作可能会尝试从源重新索引比 max_docs 更多的文档，直到成功将 max_docs 文档索引到目标位置，或者已经遍历源查询中的每个文档。

我理解意思是说： Reindex API 是 Elasticsearch Elasticsearch 中的 _reindex 功能，用于将源索引中的文档转移到目标索引中。_reindex 可以选择性地将所有文档复制到目标索引中，也可以选择性地重新索引文档的子集。与 _update_by_query 相似，_reindex 获取源的快照，但是其目标必须是不同的，因此版本冲突的可能性不大。可以通过配置 dest 元素来控制 _reindex 的乐观并发控制，支持设置 version_type、op_type 等参数。如果不设置 version_type 或将其设置为 internal，则 Elasticsearch 会将文档盲目地转移到目标位置，覆盖任何具有相同 ID 的文档。如果将 version_type 设置为 external，则 Elasticsearch 保留源的版本，创建任何缺失的文档，并更新目标索引中版本较旧的文档。

将op_type设置为 create 会导致 _reindex 仅在目标位置创建缺失的文档。现有文档会导致版本冲突。另外，因为数据流是只追加的，所以将目标数据流的重新索引请求必须具有create 的 op_type。重新索引只能向目标数据流中添加新文档，而不能更新现有文档。

默认情况下，版本冲突会中止 _reindex 过程。为了避免版本冲突而继续重新索引，可以将请求体参数 "conflicts" 设置为 proceed。在这种情况下，响应将包括��到的版本冲突的计数。请注意，处理其他错误类型不受"conflicts"参数的影响。此外，如果选择计算版本冲突，则操作可能会尝试从源中重新索引数量超过 max_docs 的文档，直到它成功地将 max_docs 文档索引到目标索引中，或者它遍历了源查询中的每个文档。

4、Running reindex asynchronously（异步运行重新索引）

https://www.elastic.co/guide/en/elasticsearch/reference/8.8/docs-reindex.html#docs-reindex-task-api

If the request contains wait_for_completion=false, Elasticsearch performs some preflight checks, launches the request, and returns a task you can use to cancel or get the status of the task. Elasticsearch creates a record of this task as a document at _tasks/<task_id>.

如果请求包含 wait_for_completion=false，Elasticsearch 会执行一些预检查，启动请求，并返回一个可以用来取消任务或获取任务状态的任务。Elasticsearch 将该任务的记录作为一个文档在 _tasks/ < task_id>创建。

我理解意思是说：当你使用 _reindex API 进行索引重建时，你可以通过 wait_for_completion 参数来控制请求的行为。当设置为 false 时，Elasticsearch 仅会执行一些前置检查，然后启动后台任务并返回一个 task ID。此时，任��会��后台异步运行，你可以通过访问 _tasks API 的接口来获取该任务的状态和进度信息，或者通过调用取消 API 取消该任务。任务的状态信息会被存储为文档在 _tasks/ 中，其中包含任务的完整详细信息，例如任务 ID、状态信息、进度信息等。这个特性对于大规模索引重建操作非常有用，因为它可以在后台异步执行这些操作，而无需阻塞主线程，可以大幅提高操作的��率和性能。同时，你也可以定期查询 _tasks API 来检查任务的状态和进度，从而可以对任务的执行情况有一个更全面的了解，以及及时调整操作策略或进行错误处理。

5、Reindex from multiple sources（从多个来源重新索引）

https://www.elastic.co/guide/en/elasticsearch/reference/8.8/docs-reindex.html#docs-reindex-from-multiple-sources

If you have many sources to reindex it is generally better to reindex them one at a time rather than using a glob pattern to pick up multiple sources. That way you can resume the process if there are any errors by removing the partially completed source and starting over. It also makes parallelizing the process fairly simple: split the list of sources to reindex and run each list in parallel.

如果您有很多需要重新索引的数据源，通常建议逐个进行重新索引，而不是使用通配符模式同时处理多个数据源。这样做的优势在于，如果遇到任何错误，您可以通过移除部分完成的数据源并重新开始来恢复进程。此外，这种方法也使得并行处理过程变得相对单：将要重新索引的数据源列表分割，并让每个子列表并行运行。

我理解意思是说：当面临多个需要重新索引的数据源时，逐个处理它们的原因有以下几点： 1、减少错误风险：逐个处理数据源可降低出错概率，提高索引准确性。2、容错性强：逐个处理数据源可以随时纠正错误。一旦发现某个数据源处理有误，立即删除该数据源，重新开始即可。 3、并行处理简单将数据源列表分割成多个子列表，然后并行运行。这不仅加快了处理速度，而且易于管理。综上所，逐个重新索引数据源是一种更可靠、高效的方法。

One-off bash scripts seem to work nicely for this:

一次性 bash 脚本似乎可以很好地解决这个问题:

for index in i1 i2 i3 i4 i5; do
        curl -HContent-Type:application/json -XPOST localhost:9200/_reindex?pretty -d'{
          "source": {
            "index": "'$index'"
          },
          "dest": {
            "index": "'$index'-reindexed"
          }
        }'
      done

6、Throttling（限流）

https://www.elastic.co/guide/en/elasticsearch/reference/8.8/docs-reindex.html#docs-reindex-throttle

Set requests_per_second to any positive decimal number (1.4, 6, 1000, etc.) to throttle the rate at which _reindex issues batches of index operations. Requests are throttled by padding each batch with a wait time. To disable throttling, set requests_per_second to -1.

将 requests_per_second 设置为任何正小数（1.4、6、1000 等），以限制 _reindex 批量发出索引操作的速率。通过在每个批次添加等待时间来对请求进行限流。要禁用限流功能，请将 requests_per_second 设置为 -1。

The throttling is done by waiting between batches so that the scroll that _reindex uses internally can be given a timeout that takes into account the padding. The padding time is the difference between the batch size divided by the requests_per_second and the time spent writing. By default the batch size is 1000, so if requests_per_second is set to 500:

限流是通过在批处理之间等待来完成的，这样_reindex在内部使用的滚动可以获得一个考虑了填充时间的超时。填充时间是批处理大小除以每秒请求数和写入时间之间的差值。默认情况下，批处理大小为1000，因此如果将每秒请求数设置为500：

        target_time = 1000 / 500 per second = 2 seconds
        wait_time = target_time - write_time = 2 seconds - .5 seconds = 1.5 seconds

Since the batch is issued as a single _bulk request, large batch sizes cause Elasticsearch to create many requests and then wait for a while before starting the next set. This is "bursty" instead of "smooth".

由于批次是作为一个_bulk请求发出的，较大的批次大小会导致Elasticsearch创建很多请求，然后等待一段时间再开始下一组请求。这种方式是"突发式"而非"平滑式"。

我理解意思是说：通过限流，可以控制请求在系统中的发出速率，从而保证服务器资源合理分配和系统的稳定运行。

7、Rethrottling（重新加速）

https://www.elastic.co/guide/en/elasticsearch/reference/8.8/docs-reindex.html#docs-reindex-rethrottle

The value of requests_per_second can be changed on a running reindex using the _rethrottle API:

正在运行的 reindex 中，可以使用 _rethrottle API 更改 requests_per_second 参数的值：

curl -X POST "localhost:9200/_reindex/r1A2WoRbTwKZ516z6NEs5A:36619/_rethrottle?requests_per_second=-1&pretty"

The task ID can be found using the tasks API.

可以使用任务 API 找到任务 ID。

Just like when setting it on the Reindex API, requests_per_second can be either -1 to disable throttling or any decimal number like 1.7 or 12 to throttle to that level. Rethrottling that speeds up the query takes effect immediately, but rethrottling that slows down the query will take effect after completing the current batch. This prevents scroll timeouts.

和在 Reindex API 中设置一样，requests_per_second 可以是 -1 表示禁用限流，或者任何小数，例如 1.7 或 12，表示限流到该级别。重新调整限流以加速查询会立即生效，但重新调整限流以减速查询将在当前批处理完成后生效。这可以防止滚动超时。

我理解意思是说：requests_per_second 是 Reindex API 中的一个参数，用于设置数据重索引时的数据传输速度。该参数的取值为浮点数，可以是负数，也可以是正数。当该参数的取值为正数时，它表示每秒传输的文档数量，也就是传输速度。当该参数的取值为负数时，表示不进行限速。

在 Elasticsearch 中，处理大量数据的操作可能会消耗大量的系统资源，从而导致系统出现延迟和超时的情况。通过设置 requests_per_second 参数，可以控制数据的传输速度，从而减少系统负载，避免出现延迟和超时的情况。

如果我们需要加快重索引的速度，可以将 requests_per_second 参数设置为比较大的值，如果我们需要降低重索引的速度，可以将该参数设置为较小的值。需要注意的是：如果我们将请求速度降低，在当前批次中，重索引的速度可能会比设置值更快，但在完成当前批次后，速度将变为设置的限制值。这样设计可以避免滚动超时的问题。

8、Slicing（切片）

https://www.elastic.co/guide/en/elasticsearch/reference/8.8/docs-reindex.html#docs-reindex-slice

Reindex supports Sliced scroll to parallelize the reindexing process. This parallelization can improve efficiency and provide a convenient way to break the request down into smaller parts.

Reindex 支持分片滚动以并行化重新索引过程。这种并行化可以提高效率，并提供一种方便的方式将请求分解成更小的部分。

Reindexing from remote clusters does not support manual or automatic slicing.

从远程集群重新索引不支持手动或自动分片。

9、Manual Slicing（手动切片）

https://www.elastic.co/guide/en/elasticsearch/reference/8.8/docs-reindex.html#docs-reindex-manual-slice

Slice a reindex request manually by providing a slice id and total number of slices to each request:

通过为每个请求提供一个切片 id 和总切片数，手动切片一个重新索引请求:

        curl -X POST "localhost:9200/_reindex?pretty" -H 'Content-Type: application/json' -d'
        {
          "source": {
            "index": "my-index-000001",
            "slice": {
              "id": 0,
              "max": 2
            }
          },
          "dest": {
            "index": "my-new-index-000001"
          }
        }'

        curl -X POST "localhost:9200/_reindex?pretty" -H 'Content-Type: application/json' -d'
        {
          "source": {
            "index": "my-index-000001",
            "slice": {
              "id": 1,
              "max": 2
            }
          },
          "dest": {
            "index": "my-new-index-000001"
          }
        }'

You can verify this works by:

你可以通过以下方式来验证:

        curl -X GET "localhost:9200/_refresh?pretty"
        curl -X POST "localhost:9200/my-new-index-000001/_search?size=0&filter_path=hits.total&pretty"

which results in a sensible total like this one:

结果就是这样一个合理的总数:

        {
            "hits": {
              "total" : {
                  "value": 120,
                  "relation": "eq"
              }
            }
          }

我理解意思是说：手动切片场景： 1、当你根据系统资源、网络带宽和查询性能需要进行细粒度控制时，手动设置切片数量。 2、当自动切片没有达到预期性能或需要根据特定场景调整切片数量时，可以使用手动切片。

10、Automatic slicing（自动切片）

https://www.elastic.co/guide/en/elasticsearch/reference/8.8/docs-reindex.html#docs-reindex-automatic-slice

You can also let _reindex automatically parallelize using Sliced scroll to slice on _id. Use slices to specify the number of slices to use:

您还可以让 _reindex 使用 Sliced 滚动自动并行化，以便在 _id 上进行分片。使用 slices 指定要使用的切片数：

curl -X POST "localhost:9200/_reindex?slices=5&refresh&pretty" -H 'Content-Type: application/json' -d'
        {
          "source": {
            "index": "my-index-000001"
          },
          "dest": {
            "index": "my-new-index-000001"
          }
        }'

You can also verify this works by:

你也可以通过以下方式来验证这种工作:

 curl -X POST "localhost:9200/my-new-index-000001/_search?size=0&filter_path=hits.total&pretty"

which results in a sensible total like this one:

结果就是这样一个合理的总数:

        {
            "hits": {
              "total" : {
                  "value": 120,
                  "relation": "eq"
              }
            }
          }

Setting slices to auto will let Elasticsearch choose the number of slices to use. This setting will use one slice per shard, up to a certain limit. If there are multiple sources, it will choose the number of slices based on the index or backing index with the smallest number of shards.

将切片设置为自动将让 Elasticsearch 选择要使用的切片数量。此设置将为每个分片使用一个切片，最多到一定的限制。如果有多个数据源，它将根据具有最少分片数量的索引或后台索引选择切片数量。

Adding slices to _reindex just automates the manual process used in the section above, creating sub-requests which means it has some quirks:

在 _reindex 中添加切片只是自动化了上面部分使用的手动过程，创建了子请求，这意味着它有一些小问题：

You can see these requests in the Tasks APIs. These sub-requests are "child" tasks of the task for the request with slices.

您可以在 Tasks APIs 中查看这些请求。这些子请求是带有slices请求的任务的 “子” 任务。

Fetching the status of the task for the request with slices only contains the status of completed slices.

仅获取带有 slices 请求的任务的状态，其中仅包含已完成 slices 的状态。

These sub-requests are individually addressable for things like cancellation and rethrottling.

这些子请求是可单独寻址的，可用于取消请求和重新调整速率等操作。

Rethrottling the request with slices will rethrottle the unfinished sub-request proportionally.

对于带有 slices 的请求重新调整速率会按比例重新调整未完成子请求的速率。

Canceling the request with slices will cancel each sub-request.

取消带有slices的请求将会取消每个子请求。

Due to the nature of slices each sub-request won’t get a perfectly even portion of the documents. All documents will be addressed, but some slices may be larger than others. Expect larger slices to have a more even distribution.

由于 slices 的性质，每个子请求得到的文档数量可能并不完全相同，但所有文档都将被处理。预期大块的 slices 分配将更加平均。

Parameters like requests_per_second and max_docs on a request with slices are distributed proportionally to each sub-request. Combine that with the point above about distribution being uneven and you should conclude that using max_docs with slices might not result in exactly max_docs documents being reindexed.

带有 slices 的请求的参数（如 requests_per_second 和 max_docs ）将按比例分配给每个子请求。结合上述有关分配不平均的观点，您应该得出结论，使用 max_docs 和 slices 可能不会导致恰好 .max_docs 个文档被重新索引。

Each sub-request gets a slightly different snapshot of the source, though these are all taken at approximately the same time.

每个子请求获得的源快照略有不同，尽管这些快照大约在同一时间拍摄。

我理解意思是说：自动切片场景： 1、当索引具有多个分片并且数据量较大时，自动切片可以根据分片数量自动进行任务切分，优化性能和效率。 2、当不确定手动设置切片数量时，可以使用自动切片来根据索引的结构自动选择合适的切片数量。

11、Picking the number of slices（选择切片的数量）

https://www.elastic.co/guide/en/elasticsearch/reference/8.8/docs-reindex.html#docs-reindex-automatic-slice

If slicing automatically, setting slices to auto will choose a reasonable number for most indices. If slicing manually or otherwise tuning automatic slicing, use these guidelines.

如果自动进行切片，将切片设置为自动将为大多数索引选择一个合理的数量。如果手动进行切片或以其他方式调整自动切片，请遵循以下准则。

Query performance is most efficient when the number of slices is equal to the number of shards in the index. If that number is large (e.g. 500), choose a lower number as too many slices will hurt performance. Setting slices higher than the number of shards generally does not improve efficiency and adds overhead.

查询性能在切片数量等于索引中分片数量时最高效。如果数字较大（例如，500），请选择较低的数字，因为过多的切片会降低性能。将切片数量设置得比分片数量高通常不会提高效率，并增加开销。

我理解意思是说：分片数量决定了数据分布和节点并行处理请求的能力。当切片数量等于分片数量时，意味着Elasticsearch可以在集群的每个分片上同时执行，这将最大程度地提高查询性能。然而，如果切片数量过大，可能引发以下问题： 1、资源争用：过的切片会导致不必要的计算和内存开销，从而降低整体性能。 2、可能导致更多的集群任务和高网络延迟，影响性能。

因此，在选择切片数量和分片数量时，我们需要寻找一个平衡。 1、如果索引的数据量适中，者分片数量在可接受范围内（例如，小于50），可以将切片数量设置为等于分片数量。 2、如果分片数量很大（例如，500个），应将切片数量设置得较小以避免过多的资源争用。

具体取决于硬件资源、数据量和查询需求，您可以根据实际情况进行实验。在实践中，选择合适的分片数量需要根据数据量、硬件资源查询负载和系统需求来综合考虑。可以在集成测试环境中尝试不同设置，以评估查询性能和系统稳定性

Indexing performance scales linearly across available resources with the number of slices.

索引性能随着切片数量线性扩展，跨可用资源进行缩放。

我理解意思是说：手动切片场景： “索引性能随切片数量线性扩展，跨可用资源进行缩放”意味着，当我们将索引切片任务划分成更多的子任务（即切片）时Elasticsearch 可以更好地利用集群中的多个节点以及这些节点上的可用资源（如CPU、内存和磁盘等）想象一下，一个重新索引任务需要处理一个非常大的现有索引，该索引具有多个分片。将此任务分解成较小的部分，可以让每个部分在不同的集群节点上并行处理。这可以极地提高索引性能，因为工作负载会分布在集群的多个节点上，而不仅仅是单个节点。

换句话说，切片越多，在集群内不同节点上并行处理任务的机会就越多，从而提高了索引能。然而请注意，存在一个最佳切片数量；超过该数量，进一步增加切片将不再带来性能提升，反而可能引入额外开销。因此，在选择切片数量时，需要平节点资源利用率和性能提升。使用自动切片功能，Elasticsearch会自动根据索引结构来确定合适的切片数量，以优化索引性能。

Whether query or indexing performance dominates the runtime depends on the documents being reindexed and cluster resources.

查询或索引性能在运行时间中占主导地位取决于被重新索引的文档以及集群资源。

12、Reindex routing（重新索引路由）

https://www.elastic.co/guide/en/elasticsearch/reference/8.8/docs-reindex.html#docs-reindex-routing

By default if _reindex sees a document with routing then the routing is preserved unless it’s changed by the script. You can set routing on the dest request to change this:

默认情况下，如果 _reindex 见到一个带有路由的文档，那么路由将被保留，除非它被脚本更改。您可以在 dest 请求上设置路由来改变这个：

keep

　　Sets the routing on the bulk request sent for each match to the routing on the match. This is the default value.

将每个匹配项发送的批量请求的路由设置为匹配项上的路由。这是默认值。

discard

　　Sets the routing on the bulk request sent for each match to null.

将每个匹配项发送的批量请求的路由设置为 null。

=<some text>

　　Sets the routing on the bulk request sent for each match to all text after the =.

将每个匹配项发送的批量请求的路由设置为等号之后的所有文本。

For example, you can use the following request to copy all documents from the source with the company name cat into the dest with routing set to cat.

例如，您可以使用以下请求将源中公司名为 cat 的所有文档复制到路由设置为 cat 的目标中。

curl -X POST "localhost:9200/_reindex?pretty" -H 'Content-Type: application/json' -d'
        {
          "source": {
            "index": "source",
            "query": {
              "match": {
                "company": "cat"
              }
            }
          },
          "dest": {
            "index": "dest",
            "routing": "=cat"
          }
        }'

By default _reindex uses scroll batches of 1000. You can change the batch size with the size field in the source element:

默认情��下，_reindex 使用的是1000个滚动批处理。您可以通过源元素中的 size 字段更改批处理大小：

curl -X POST "localhost:9200/_reindex?pretty" -H 'Content-Type: application/json' -d'
        {
          "source": {
            "index": "source",
            "size": 100
          },
          "dest": {
            "index": "dest",
            "routing": "=cat"
          }
        }'

13、Reindex with an ingest pipeline（使用 ingest pipeline 重新索引）

https://www.elastic.co/guide/en/elasticsearch/reference/8.8/docs-reindex.html#reindex-with-an-ingest-pipeline

Reindex can also use the Ingest pipelines feature by specifying a pipeline like this:

Reindex 还可以通过指定如下管道来使用 Ingest pipelines（https://www.elastic.co/guide/en/elasticsearch/reference/8.8/ingest.html）特性:

curl -X POST "localhost:9200/_reindex?pretty" -H 'Content-Type: application/json' -d'
        {
          "source": {
            "index": "source"
          },
          "dest": {
            "index": "dest",
            "pipeline": "some_ingest_pipeline"
          }
        }'

我理解意思是说： Elasticsearch 8 的 Ingest Pipeline 是一个用于在数据索引到 Elasticsearch 之前对数据进行预处理的功能。它是一种强大的数据处理机制，通过使用一组预定义的处理器（processor）按顺序执行处理操作。处理器可以执行多种任务，如提取、转换、过滤和改变数据。这样，在数据入库之前，我们可以根据需求来优化和清洗数据，以便更好地满足查询性能和分析需求。

Ingest Pipeline 解决了以下问题： 1、数据预处理：在数据被存储到 Elasticsearch 之前，通过 Ingest Pipeline 可以对数据进行清洗、标准化或丰富等操作，确保进入的数据符合业务要求。

2、整合第三方数据源：某些数据源来自第三方平台，这些平台输出的数据格式可能不符合 Elasticsearch 的存储结构。Ingest Pipeline 允许我们在存储数据之前对这些数据进行调整和转换，以便更好地合多种数据源。

3、减少重复工作：预处理数据的过程通常可实现在许多不同的环节（例如，ET过程中或者日志收集）。采用 Ingest Pipeline 可使相同的操作直接在 Elasticsearch 中集成并执行，从而减少了在其他阶段的重复工作。

4、提高搜索和分析效果：通过 Ingest 对数据进行优化处理，可以提高 Elasticsearch 的搜索和分析能力，如更好地处理日期类型、分词、标签化、地理位置信息和 IP 地址等，从而提供更高效和精准的搜索结果。

总之，Elasticsearch 8 的 Ingest Pipeline 是一个实用的特性，可帮助对数据进行预处理操作。通过使用一系列处理器来准备和优化数据，它解决了数据清洗、整合、搜索和分析等面的各种问题。在实际应用中，根据不同业务场景和需求，使用 Ingest Pipeline 可以提高 Elasticsearch 的性能和可用性。

而在重新索引（Reindex）过程中使用 Ingest Pipeline，可以让您在将数据从源索引复制到目标索引时对数据进行预处理。这意味着您可以在重新索引过程中清理、转换或丰富数据。这是一个强大的功能，允许您优化数据以满足特定的存储、搜索和分析要求。

14、Reindex select documents with a query（使用查询重新索引选择文档）

https://www.elastic.co/guide/en/elasticsearch/reference/8.8/docs-reindex.html#docs-reindex-select-query

You can limit the documents by adding a query to the source. For example, the following request only copies documents with a user.id of kimchy into my-new-index-000001:

您可以通过在源中添加查询来限制文档。例如，以下请求仅将 user.id 为 kimchy 的文档复制到 my-new-index-000001：

curl -X POST "localhost:9200/_reindex?pretty" -H 'Content-Type: application/json' -d'
        {
          "source": {
            "index": "my-index-000001",
            "query": {
              "term": {
                "user.id": "kimchy"
              }
            }
          },
          "dest": {
            "index": "my-new-index-000001"
          }
        }'

15、Reindex from multiple sources（从多个来源重新索引）

https://www.elastic.co/guide/en/elasticsearch/reference/8.8/docs-reindex.html#docs-reindex-multiple-sources

The index attribute in source can be a list, allowing you to copy from lots of sources in one request. This will copy documents from the my-index-000001 and my-index-000002 indices:

source 中的 index 属性可以是一个列表，允许您在一个请求中从多个源复制。这将从 my-index-000001 和 my-index-000002 索引中复制文档：

curl -X POST "localhost:9200/_reindex?pretty" -H 'Content-Type: application/json' -d'
        {
          "source": {
            "index": ["my-index-000001", "my-index-000002"]
          },
          "dest": {
            "index": "my-new-index-000002"
          }
        }'

The Reindex API makes no effort to handle ID collisions so the last document written will "win" but the order isn’t usually predictable so it is not a good idea to rely on this behavior. Instead, make sure that IDs are unique using a script.

Reindex API 不会处理 ID 冲突，因此最后写入的文档将“胜出”，但通常顺序不可预测，因此依赖这种行为并不明智。相反，应使用脚本确保 ID 是唯一的。

16、Reindex select fields with a source filter（使用源过滤重新索引选定字段）

https://www.elastic.co/guide/en/elasticsearch/reference/8.8/docs-reindex.html#docs-reindex-filter-source

You can use source filtering to reindex a subset of the fields in the original documents. For example, the following request only reindexes the user.id and _doc fields of each document:

您可以使用源过滤来重新索引原始文档中的一部分字段。例如，以下请求仅重新索引每个文档的 user.id 和 _doc 字段：

curl -X POST "localhost:9200/_reindex?pretty" -H 'Content-Type: application/json' -d'
        {
          "source": {
            "index": "my-index-000001",
            "_source": ["user.id", "_doc"]
          },
          "dest": {
            "index": "my-new-index-000001"
          }
        }'

我理解意思是说：使用源过滤重新索引选定字段的意义在于为 Elasticsearch 8 这样的场景提高效率和灵活性。在某些情况下，您可能只需要从原始文档中重新索引某些特定字段，而不是整个文档（意味着在执行重新索引操作时，我们仅选择一部分字段进行复制，而不是完全复制原文档的所有字段）。这样可以减少不必要的数据传输和存储，从而提高重新索引操作的性能。通过对特定字段进行重新索引（利用源过滤），您可以更好地组织和优化索引结构，以便快速查询和分析。这也有助于合并多个索引中的部分数据，或仅传输和备份关键数据。总之，在 Elasticsearch 8 等场景中使用源过滤重新索引选定字段，可以提高操作效率和数据灵活性，使索引结构更合理和易于查询。

17、Reindex to change the name of a field（重新索引以更改字段的名称）

https://www.elastic.co/guide/en/elasticsearch/reference/8.8/docs-reindex.html#docs-reindex-change-name

_reindex can be used to build a copy of an index with renamed fields. Say you create an index containing documents that look like this:

_reindex 可用于构建带有重命名字段的索引副本。假设您创建了一个包含如下所示的文档的索引：

curl -X POST "localhost:9200/my-index-000001/_doc/1?refresh&pretty" -H 'Content-Type: application/json' -d'
        {
          "text": "words words",
          "flag": "foo"
        }'

but you don’t like the name flag and want to replace it with tag. _reindex can create the other index for you:

但您不喜歡字段名 "flag"，希望用 "tag" 替換。_reindex 可以為您創建另一個索引：

curl -X POST "localhost:9200/_reindex?pretty" -H 'Content-Type: application/json' -d'
        {
          "source": {
            "index": "my-index-000001"
          },
          "dest": {
            "index": "my-new-index-000001"
          },
          "script": {
            "source": "ctx._source.tag = ctx._source.remove(\"flag\")"
          }
        }'

Now you can get the new document:

现在，您可以获得新的文档：

curl -X GET "localhost:9200/my-new-index-000001/_doc/1?pretty"

which will return:

它将返回：

        {
            "found": true,
            "_id": "1",
            "_index": "my-new-index-000001",
            "_version": 1,
            "_seq_no": 44,
            "_primary_term": 1,
            "_source": {
              "text": "words words",
              "tag": "foo"
            }
          }

我理解意思是说：在 Elasticsearch 8 中，使用 _reindex 构建带有重命名字段的索引副本具有一定的意义。它主要解决了以下问题：

1、数据结构变化：随着业务需求和数据模型的演进，字段名称可能需要更改以更准确地反映其含义。例如，最初使用 "flag" 作为字段名，但随后发现 "tag" 更适合表示其内容。使用 _reindex，您可以轻松更改字段名称，以使其与新的数据结构和需求保持一致。

2、索引优化：在实际操作中，可能会遇到由于历史原因或团队内部沟通问题而导致的字段命名不一致。这可能会导致混乱和困难的查询操作。通过使用 _reindex 进行字段重命名，您可以统一和优化索引结构，提高查询性能和易用性。

3、数据迁移：当将数据从一个系统迁移到另一个系统，或者当两个不同系统需要集成时，字段名称可能需要调整以确保一致性。_reindex 可以帮助您在保留原始数据的同时，调整名称以实现不同系统之间的兼容性。

18、Reindex daily indices（重新索引每日indices）

https://www.elastic.co/guide/en/elasticsearch/reference/8.8/docs-reindex.html#docs-reindex-daily-indices

You can use _reindex in combination with Painless to reindex daily indices to apply a new template to the existing documents.

您可以将 _reindex 与 Painless 结合使用，将现有文档重新索引到每日索引中以应用新的模板。

我理解意思是说：将 _reindex 与 Painless （Painless 是 Elasticsearch 8 中的一种内置脚本语言。它是一种安全、高性能、和快速的脚本语言，专为 Elasticsearch 和 Lucene 所设计， Painless 成为实现高级查询、数据处理和定制功能的关键工具。）结合使用，以将现有文档重新索引到每日索引以应用新的模板，这样做可以解决以下场景和问题：

1、数据模板变更：当您更新或修改现有索引模板时，已有的文档可能仍在使用旧模板。通过将 _reindex 与 Painless 结合使用，您可以将现有文档应用到新的模板，从而确保数据结构与最新的模板保持一致。

2、性能优化：索引模板中的设置和字段影响查询和分析性能。如果新的模板对这些设置进行了优化，利用 _reindex 和 Painless 可以将优化应用到已有的文档，从而改善性能。

3、滚动索引：在某些情况下，您可能会为每天的数据创建一个新的索引。然后，根据新的模板将现有文档重新索引到每日索引中。这有助于实现资源有效地管理和保持索引的大小可控。

4、数据清理和追溯性：使用 _reindex 结合 Painless 重新索引每日数据可以帮助用户实现数据清理和追溯性。在重新索引过程中，将不必要的数据字段移除或者格式化为新的命名方案，使得数据保持干净和有序。

总之，在上述场景下，将 _reindex 与 Painless 结合使用可以实现模板更新、性能优化、滚动索引和数据清理等目标，从而提高数据可用性和查询性能。

Assuming you have indices that contain documents like:

假设您有包含以下文档的索引:

        curl -X PUT "localhost:9200/metricbeat-2016.05.30/_doc/1?refresh&pretty" -H 'Content-Type: application/json' -d'
        {"system.cpu.idle.pct": 0.908}
        '
        curl -X PUT "localhost:9200/metricbeat-2016.05.31/_doc/1?refresh&pretty" -H 'Content-Type: application/json' -d'
        {"system.cpu.idle.pct": 0.105}
        '

The new template for the metricbeat-* indices is already loaded into Elasticsearch, but it applies only to the newly created indices. Painless can be used to reindex the existing documents and apply the new template.

新的 metricbeat-* 索引模板已经加载到 Elasticsearch 中，但它仅适用于新创建的索引。Painless 可用于重新索引现有文档并应用新模板。

The script below extracts the date from the index name and creates a new index with -1 appended. All data from metricbeat-2016.05.31 will be reindexed into metricbeat-2016.05.31-1.

以下脚本从索引名称中提取日期并创建一个附加 -1 的新索引。 metricbeat-2016.05.31 中的所有数据将被重新索引到 metricbeat-2016.05.31-1。

        curl -X POST "localhost:9200/_reindex?pretty" -H 'Content-Type: application/json' -d'
        {
            "source": {
              "index": "metricbeat-*"
            },
            "dest": {
              "index": "metricbeat"
            },
            "script": {
              "lang": "painless",
              "source": "ctx._index = 'metricbeat-' + (ctx._index.substring('metricbeat-'.length(), ctx._index.length())) + '-1'"
            }
          }

我理解意思是说：这个 curl 命令是用于在 Elasticsearch 中执行 _reindex 操作的。具体来说，它会将一个或多个源索引（source index）中的文档重新索引到目标索引（destination [ˌdεstəˈneʃən] index）。下面我们详细解释一下这个命令中的各个部分：

1、curl -X POST "localhost:9200/_reindex?pretty"：这部分使用 curl 发送一个 HTTP POST 请求到 Elasticsearch 服务器的 _reindex API。localhost:9200 是 Elasticsearch 服务器的地址（假设它运行在本地）。?pretty 参数会让服务器以易读的格式返回响应。

2、-H 'Content-Type: application/json'：这部分设置 HTTP 请求头，声明请求正文（payload）的内容类型是 JSON。

3、-d：这部分表示接下来的字符串是请求的正文（payload）。

4、 "source": "ctx._index = 'metricbeat-' + (ctx._index.substring('metricbeat-'.length(), ctx._index.length())) + '-1'" ：这部分是一个 JSON 对象，描述了重建索引操作的具设置，script"对象包含两个字段："lang"和"source"。"source"字段包含实际脚本代码。我们分步骤详细解释这段代码：

a. ctx._index：是目前正在处理的文档所在的源索引名称。

b. 'beat-'：是目标索引名称的前缀。

c. ctx._index.substring('metricbeat-'.length(), ctx._index.length())：这部分代码提取源索引名称中 'metricbeat-' 后面的部分。

5、源索引名称中'metricbeat-'后面的部分。

a. '-1'：这部分代码是在重新命名索引时添加后缀。

b. 整个脚本的目的是将源索引名称中的 'metricbeat-' 替换为 'metricbeat-...-1' 形式的新名称。例如，如果源索引名称是 'metricbeat-2023'，那么 ctx._index 的值将被修改为 'metricbeat-2023-1'。

6、最后，这个脚本用于在数据重建的过程中修改索引名称，并将新的索引名称作目标索引存储在 Elasticsearch 中。

最后，这个命令将把所有符合 "metricbeat-*" 模式的源索引中的文档重新索引到新的 "metricbeat" 索引，并根据 Painless 脚本修改它们的索引名。

All documents from the previous metricbeat indices can now be found in the *-1 indices.

现在，以前的 metricbeat 索引中的所有文档都可以在 *-1 索引中找到。

        GET metricbeat-2016.05.30-1/_doc/1
        GET metricbeat-2016.05.31-1/_doc/1

19、Extract a random subset of the source（提取源数据的随机子集）

https://www.elastic.co/guide/en/elasticsearch/reference/8.8/docs-reindex.html#docs-reindex-api-subset

_reindex can be used to extract a random subset of the source for testing:

_ reindex 可以用来提取源代码的一个随机子集进行测试:

curl -X POST "localhost:9200/_reindex?pretty" -H 'Content-Type: application/json' -d'
        {
          "max_docs": 10,
          "source": {
            "index": "my-index-000001",
            "query": {
              "function_score" : {
                "random_score" : {},
                "min_score" : 0.9    
              }
            }
          },
          "dest": {
            "index": "my-new-index-000001"
          }
        }'

我理解意思是说：在Elasticsearch中，"_reindex"可用于提取源数据的随机子集，主要用于测试场景。应用场景举例：

1、性能测试：在进行性能测试时，您可能需要使用数据的一部分来模拟特定的工作负载。通过提取源数据的一个随机子集，您可以获得一个更小的数据样本，从而快速地对系统的性能进行测试。 2、功能测试：在开发或调试中，提取一个随机子集可以方便您对新功能或查询执行进行测试，而无需加载整个数据集。这样可缩短调试和开发时间。 3、数据分析：在对大数据集进行分析时，您可能想要获取一个代表性的样本进行初步分。提取随机子集可以帮助您在不对整个数据集进行彻底分析的情况下，快速获得数据的基本趋势特征。

在这些场景下，"_reindex"操作能够高效地提取源数据的一个随机子集，并将其存储在新的索引中，为后续的测试或分析提供便利。

20、Modify documents during reindexing（在重新索引期间修改文档）

https://www.elastic.co/guide/en/elasticsearch/reference/8.8/docs-reindex.html#docs-reindex-api-subset

Like _update_by_query, _reindex supports a script that modifies the document. Unlike _update_by_query, the script is allowed to modify the document’s metadata. This example bumps the version of the source document:

与 _update_by_query 类似，_reindex 支持修改文档的脚本。与 _update_by_query 不同的是，脚本允许修改文档的元数据。这个示例将源文档的版本升级：

curl -X POST "localhost:9200/_reindex?pretty" -H 'Content-Type: application/json' -d'
        {
          "source": {
            "index": "my-index-000001"
          },
          "dest": {
            "index": "my-new-index-000001",
            "version_type": "external"
          },
          "script": {
            "source": "if (ctx._source.foo == 'bar') {ctx._version++; ctx._source.remove('foo')}",
            "lang": "painless"
          }
        }'

21、Reindex from remote（跨集群索引）

https://www.elastic.co/guide/en/elasticsearch/reference/8.8/docs-reindex.html#reindex-from-remote

Reindex supports reindexing from a remote Elasticsearch cluster:

Reindex 支持从远程 Elasticsearch 集群进行重新索引:

curl -X POST "localhost:9200/_reindex?pretty" -H 'Content-Type: application/json' -d'
        {
          "source": {
            "remote": {
              "host": "http://otherhost:9200",
              "username": "user",
              "password": "pass"
            },
            "index": "my-index-000001",
            "query": {
              "match": {
                "test": "data"
              }
            }
          },
          "dest": {
            "index": "my-new-index-000001"
          }
        }'

The host parameter must contain a scheme, host, port (e.g. https://otherhost:9200), and optional path (e.g. https://otherhost:9200/proxy). The username and password parameters are optional, and when they are present _reindex will connect to the remote Elasticsearch node using basic auth. Be sure to use https when using basic auth or the password will be sent in plain text. There are a range of settings available to configure the behaviour of the https connection.

host 参数必须包含一个方案、主机、端口（例如：https://otherhost:9200）以及可选的路径（例如：https://otherhost:9200/proxy）。username 和 password 参数是可选的，当它们存在时，_reindex 将使用基本身份验证方式连接到远程 Elasticsearch 节点。在使用本身份验证时，请务必使用 https，否则密码将以明文形式发送。有一系列设置可用于配置 https 连接的行为。

When using Elastic Cloud, it is also possible to authenticate against the remote cluster through the use of a valid API key:

在使用 Elastic Cloud 时，还可以通过使用有效的 API 密钥对远程集群进行身份验证:

curl -X POST "localhost:9200/_reindex?pretty" -H 'Content-Type: application/json' -d'
        {
          "source": {
            "remote": {
              "host": "http://otherhost:9200",
              "headers": {
                "Authorization": "ApiKey API_KEY_VALUE"
              }
            },
            "index": "my-index-000001",
            "query": {
              "match": {
                "test": "data"
              }
            }
          },
          "dest": {
            "index": "my-new-index-000001"
          }
        }'

Remote hosts have to be explicitly allowed in elasticsearch.yml using the reindex.remote.whitelist property. It can be set to a comma delimited list of allowed remote host and port combinations. Scheme is ignored, only the host and port are used. For example:

远程主机需要在 elasticsearch.yml 中使用 reindex.remote.whitelist 属性进行明确允许。它可以设置为允许的远程主机和端口组合的逗号分隔列表。忽略方案，仅使用主机和端口。例如：

reindex.remote.whitelist: "otherhost:9200, another:9200, 127.0.10.*:9200, localhost:*"

The list of allowed hosts must be configured on any nodes that will coordinate the reindex.

允许的主机列表必须在将协调重新索引的任何节点上进行配置。

This feature should work with remote clusters of any version of Elasticsearch you are likely to find. This should allow you to upgrade from any version of Elasticsearch to the current version by reindexing from a cluster of the old version.

此功能应该与您可能找到的任何版本的Elasticsearch的远程集群兼容。这应该允许您从旧版本的集群重新索引到当前版本，从而完成升级。

Elasticsearch does not support forward compatibility across major versions. For example, you cannot reindex from a 7.x cluster into a 6.x cluster.

Elasticsearch 不支持跨主要版本的前向兼容性。例如，您不能将7. x 集群重新索引到6. x 集群。

To enable queries sent to older versions of Elasticsearch the query parameter is sent directly to the remote host without validation or modification.

为了启用发送到老版本 Elasticsearch 的查询，查询参数将直接发送到远程主机，而不需要进行验证或修改。

Reindexing from remote clusters does not support manual or automatic slicing.

从远程集群重新索引不支持手动或自动切片。

Reindexing from a remote server uses an on-heap buffer that defaults to a maximum size of 100mb. If the remote index includes very large documents you’ll need to use a smaller batch size. The example below sets the batch size to 10 which is very, very small.

从远程服务器重新索引使用一个默认最大尺寸为100MB的堆缓冲区。如果远程索引包括非常大的文档，您需要使用一个较小的批量大小。下面的例子将批量大小设置为10，这是非常非常小的。

curl -X POST "localhost:9200/_reindex?pretty" -H 'Content-Type: application/json' -d'
        {
          "source": {
            "remote": {
              "host": "http://otherhost:9200"
            },
            "index": "source",
            "size": 10,
            "query": {
              "match": {
                "test": "data"
              }
            }
          },
          "dest": {
            "index": "dest"
          }
        }'

It is also possible to set the socket read timeout on the remote connection with the socket_timeout field and the connection timeout with the connect_timeout field. Both default to 30 seconds. This example sets the socket read timeout to one minute and the connection timeout to 10 seconds:

还可以使用socket_timeout字段设置远程连接的套接字读取超时时间，并使用connect_timeout字段设置连接超时时间。两者的默认值均为30秒。以下示例将套接字读取超时时间设置为一分钟，连接超时时间设置为10秒：

curl -X POST "localhost:9200/_reindex?pretty" -H 'Content-Type: application/json' -d'
        {
          "source": {
            "remote": {
              "host": "http://otherhost:9200",
              "socket_timeout": "1m",
              "connect_timeout": "10s"
            },
            "index": "source",
            "query": {
              "match": {
                "test": "data"
              }
            }
          },
          "dest": {
            "index": "dest"
          }
        }'

22、Configuring SSL parameters（配置 SSL 参数）

https://www.elastic.co/guide/en/elasticsearch/reference/8.8/docs-reindex.html#reindex-ssl

Reindex from remote supports configurable SSL settings. These must be specified in the elasticsearch.yml file, with the exception of the secure settings, which you add in the Elasticsearch keystore. It is not possible to configure SSL in the body of the _reindex request.

从远程重建索引支持可配置的 SSL 设置。这些须在 elasticsearch.yml 文件中指定，除了安全设置，您需要在 Elasticsearch 密钥库中添加安全设置。在 _reindex 请求的主体中配置 SSL 是不可能的。

posted @ 2023-06-08 11:24 左扬阅读(207) 评论(0) 编辑收藏举报

刷新页面返回顶部

左扬(你们的胃叫胃，孤的叫胃PLUS)

读书不觉春已深，一寸光阴一寸金。