重要
Reindex不会尝试设置目标索引。它不会复制源索引的设置信息。您应该在运行
_reindex操作之前设置目标索引，包括设置映射，分片数，副本等。
_reindex的最基本形式只是将文档从一个索引复制到另一个索引。下面将文档从twitter索引复制到new_twitter索引中：
POST _reindex
{
"source": {
"index": "twitter"
},
"dest": {
"index": "new_twitter"
}
}
这将会返回类似以下的信息：
{
"took" : 147,
"timed_out": false,
"created": 120,
"updated": 0,
"deleted": 0,
"batches": 1,
"version_conflicts": 0,
"noops": 0,
"retries": {
"bulk": 0,
"search": 0
},
"throttled_millis": 0,
"requests_per_second": -1.0,
"throttled_until_millis": 0,
"total": 120,
"failures" : [ ]
}
和_update_by_query一样，_reindex获取源索引的快照，但其目标索引必须是不同的索引，因此不会发生版本冲突。 dest元素可以像索引API一样进行配置，以控制乐观并发控制。只需将version_type 空着（像上面一样）或将version_type设置为internal则Elasticsearch强制性的将文档转储到目标中，覆盖具有相同类型和ID的任何内容：
POST _reindex
{
"source": {
"index": "twitter"
},
"dest": {
"index": "new_twitter",
"version_type": "internal"
}
}
将version_type设置为external将导致Elasticsearch从源文件中保留版本，创建缺失的所有文档，并更新在目标索引中比源索引中版本更老的所有文档：
POST _reindex
{
"source": {
"index": "twitter"
},
"dest": {
"index": "new_twitter",
"version_type": "external"
}
}
设置op_type为create将导致_reindex仅在目标索引中创建缺少的文档。所有存在的文档将导致版本冲突：
POST _reindex
{
"source": {
"index": "twitter"
},
"dest": {
"index": "new_twitter",
"op_type": "create"
}
}
默认情况下，版本冲突将中止_reindex进程，但您可以通过请求体设置"conflict":"proceed"来在冲突时进行计数：
POST _reindex
{
"conflicts": "proceed",
"source": {
"index": "twitter"
},
"dest": {
"index": "new_twitter",
"op_type": "create"
}
}
您可以通过向source添加type或添加query来限制文档。下面会将kimchy发布的tweet复制到new_twitter中：
POST _reindex
{
"source": {
"index": "twitter",
"type": "tweet",
"query": {
"term": {
"user": "kimchy"
}
}
},
"dest": {
"index": "new_twitter"
}
}
source中的index和type都可以是一个列表，允许您在一个请求中从大量的来源进行复制。下面将从twitter和blog索引中的tweet和post类型中复制文档。它也包含twitter索引中post类型以及blog索引中的tweet类型。如果你想更具体，你将需要使用query。它也没有努力处理ID冲突。目标索引将保持有效，但由于迭代顺序定义不正确，预测哪个文档可以保存下来是不容易的。
POST _reindex
{
"source": {
"index": ["twitter", "blog"],
"type": ["tweet", "post"]
},
"dest": {
"index": "all_together"
}
}
还可以通过设置大小限制处理的文档的数量。下面只会将单个文档从twitter复制到new_twitter：
POST _reindex
{
"size": 1,
"source": {
"index": "twitter"
},
"dest": {
"index": "new_twitter"
}
}
如果你想要从twitter索引获得一个特定的文档集合你需要排序。排序使滚动效率更低，但在某些情况下它是值得的。如果可能，更喜欢更多的选择性查询size和sort。这将从twitter复制10000个文档到new_twitter：
POST _reindex
{
"size": 10000,
"source": {
"index": "twitter",
"sort": { "date": "desc" }
},
"dest": {
"index": "new_twitter"
}
}
source部分支持搜索请求中支持的所有元素。例如，只使用原始文档的一部分字段，使用源过滤如下所示：
POST _reindex
{
"source": {
"index": "twitter",
"_source": ["user", "tweet"]
},
"dest": {
"index": "new_twitter"
}
}
像update_by_query一样，_reindex支持修改文档的脚本。与_update_by_query不同，脚本允许修改文档的元数据。此示例修改了源文档的版本：
POST _reindex
{
"source": {
"index": "twitter"
},
"dest": {
"index": "new_twitter",
"version_type": "external"
},
"script": {
"inline": "if (ctx._source.foo == 'bar') {ctx._version++; ctx._source.remove('foo')}",
"lang": "painless"
}
}
就像在_update_by_query中一样，您可以设置ctx.op来更改在目标索引上执行的操作：
noop
如果您的脚本决定不必进行任何更改，请设置 ctx.op ="noop" 。这将导致_update_by_query 从其更新中忽略该文档。这个没有操作将被报告在响应体的 noop 计数器上。
delete
如果您的脚本决定必须删除该文档，请设置ctx.op="delete"。删除将在响应体的 deleted 计数器中报告。
将ctx.op设置为其他任何内容都是错误。在ctx中设置任何其他字段是一个错误。
想想可能性！只要小心点，有很大的力量...你可以改变：
_id_type_index_version_routing_parent将_version设置为null或从ctx映射清除就像在索引请求中不发送版本一样。这将导致目标索引中的文档被覆盖，无论目标版本或_reindex请求中使用的版本类型如何。
默认情况下，如果_reindex看到具有路由的文档，则路由将被保留，除非脚本被更改。您可以根据dest请求设置routing来更改：
keep
将批量请求的每个匹配项的路由设置为匹配上的路由。默认值。
discard
将批量请求的每个匹配项的路由设置为null。
=<某些文本>
将批量请求的每个匹配项的路由设置为`=`之后的文本。
例如，您可以使用以下请求将source索引的所有公司名称为cat的文档复制到路由设置为cat的dest索引。
POST _reindex
{
"source": {
"index": "source",
"query": {
"match": {
"company": "cat"
}
}
},
"dest": {
"index": "dest",
"routing": "=cat"
}
}
默认情况下，_reindex批量滚动处理大小为1000.您可以在source元素中指定size字段来更改批量处理大小：
POST _reindex
{
"source": {
"index": "source",
"size": 100
},
"dest": {
"index": "dest",
"routing": "=cat"
}
}
Reindex也可以使用[Ingest Node]功能来指定pipeline, 就像这样：
POST _reindex
{
"source": {
"index": "source"
},
"dest": {
"index": "dest",
"pipeline": "some_ingest_pipeline"
}
}
Reindex支持从远程Elasticsearch群集重建索引：
POST _reindex
{
"source": {
"remote": {
"host": "http://otherhost:9200",
"username": "user",
"password": "pass"
},
"index": "source",
"query": {
"match": {
"test": "data"
}
}
},
"dest": {
"index": "dest"
}
}
host参数必须包含scheme，host和port（例如 https：// otherhost:9200）。用户名和密码参数是可选的，当它们存在时，索引将使用基本认证连接到远程Elasticsearch节点。使用基本认证时请务必使用https，密码将以纯文本格式发送。
必须在elasticsearch.yaml中使用reindex.remote.whitelist属性将远程主机明确列入白名单。它可以设置为允许的远程host和port组合的逗号分隔列表（例如otherhost:9200,another:9200,127.0.10.*:9200,localhost:*）。白名单忽略了scheme ——仅使用主机和端口。
此功能应适用于您可能找到的任何版本的Elasticsearch的远程群集。这应该允许您从任何版本的Elasticsearch升级到当前版本，通过从旧版本的集群重新建立索引。
要启用发送到旧版本Elasticsearch的查询，query参数将直接发送到远程主机，无需验证或修改。
来自远程服务器的重新索引使用默认为最大大小为100mb的堆栈缓冲区。如果远程索引包含非常大的文档，则需要使用较小的批量大小。下面的示例设置非常非常小的批量大小10。
POST _reindex
{
"source": {
"remote": {
"host": "http://otherhost:9200"
},
"index": "source",
"size": 10,
"query": {
"match": {
"test": "data"
}
}
},
"dest": {
"index": "dest"
}
}
也可以使用socket_timeout字段在远程连接上设置socket的读取超时，并使用connect_timeout字段设置连接超时。两者默认为三十秒。此示例将套接字读取超时设置为一分钟，并将连接超时设置为十秒：
POST _reindex
{
"source": {
"remote": {
"host": "http://otherhost:9200",
"socket_timeout": "1m",
"connect_timeout": "10s"
},
"index": "source",
"query": {
"match": {
"test": "data"
}
}
},
"dest": {
"index": "dest"
}
}
除了标准参数像pretty之外，“Reindex API”还支持refresh、wait_for_completion、wait_for_active_shards、timeout以及requests_per_second。
发送refresh将在更新请求完成时更新索引中的所有分片。这不同于 Index API 的refresh参数，只会导致接收到新数据的分片被索引。
如果请求包含wait_for_completion=false，那么Elasticsearch将执行一些预检检查、启动请求、然后返回一个任务，可以与Tasks API一起使用来取消或获取任务的状态。Elasticsearch还将以.tasks/task/${taskId}作为文档创建此任务的记录。这是你可以根据是否合适来保留或删除它。当你完成它时，删除它可以让Elasticsearch回收它使用的空间。
wait_for_active_shards控制在继续请求之前必须有多少个分片必须处于活动状态，详见这里。timeout控制每个写入请求等待不可用分片变成可用的时间。两者都能正确地在Bulk API中工作。
requests_per_second可以设置为任何正数（1.4，6，1000等），来作为“delete-by-query”每秒请求数的节流阀数字，或者将其设置为-1以禁用限制。节流是在批量批次之间等待，以便它可以操纵滚动超时。等待时间是批次完成的时间与request_per_second * requests_in_the_batch的时间之间的差异。由于分批处理没有被分解成多个批量请求，所以会导致Elasticsearch创建许多请求，然后等待一段时间再开始下一组。这是“突发”而不是“平滑”。默认值为-1。
JSON响应类似如下：
{
"took" : 639,
"updated": 0,
"created": 123,
"batches": 1,
"version_conflicts": 2,
"retries": {
"bulk": 0,
"search": 0
}
"throttled_millis": 0,
"failures" : [ ]
}
took
从整个操作的开始到结束的毫秒数。
updated
成功更新的文档数。
upcreateddated
成功创建的文档数。
batches
通过查询更新的滚动响应数量。
version_conflicts
根据查询更新时，版本冲突的数量。
retries
根据查询更新的重试次数。bluk 是重试的批量操作的数量，search 是重试的搜索操作的数量。
throttled_millis
请求休眠的毫秒数，与`requests_per_second`一致。
failures
失败的索引数组。如果这是非空的，那么请求因为这些失败而中止。请参阅 conflicts 来如何防止版本冲突中止操作。
您可以使用Task API获取任何正在运行的重建索引请求的状态：
GET _tasks?detailed=true&actions=*/update/byquery
响应会类似如下：
{
"nodes" : {
"r1A2WoRbTwKZ516z6NEs5A" : {
"name" : "r1A2WoR",
"transport_address" : "127.0.0.1:9300",
"host" : "127.0.0.1",
"ip" : "127.0.0.1:9300",
"attributes" : {
"testattr" : "test",
"portsfile" : "true"
},
"tasks" : {
"r1A2WoRbTwKZ516z6NEs5A:36619" : {
"node" : "r1A2WoRbTwKZ516z6NEs5A",
"id" : 36619,
"type" : "transport",
"action" : "indices:data/write/reindex",
"status" : { //①
"total" : 6154,
"updated" : 3500,
"created" : 0,
"deleted" : 0,
"batches" : 4,
"version_conflicts" : 0,
"noops" : 0,
"retries": {
"bulk": 0,
"search": 0
},
"throttled_millis": 0
},
"description" : ""
}
}
}
}
}
① 此对象包含实际状态。它就像是响应json，重要的添加total字段。 total是重建索引希望执行的操作总数。您可以通过添加的updated、created和deleted的字段来估计进度。当它们的总和等于total字段时，请求将完成。
使用任务id可以直接查找任务：
GET /_tasks/taskId:1
这个API的优点是它与wait_for_completion=false集成，以透明地返回已完成任务的状态。如果任务完成并且wait_for_completion=false被设置，那么它将返回results或error字段。此功能的成本是wait_for_completion=false在.tasks/task/${taskId}创建的文档，由你自己删除该文件。
所有重建索引都能使用Task Cancel API取消：
POST _tasks/task_id:1/_cancel
可以使用上面的任务API找到task_id。
取消应尽快发生，但可能需要几秒钟。上面的任务状态API将继续列出任务，直到它被唤醒取消自身。
request_per_second的值可以在通过查询删除时使用_rethrottle API更改：
POST _update_by_query/task_id:1/_rethrottle?requests_per_second=-1
可以使用上面的任务API找到task_id。
就像在_update_by_query API中设置它一样，request_per_second可以是-1来禁用限制，或者任何十进制数字，如1.7或12，以节制到该级别。加速查询的会立即生效，但是在完成当前批处理之后，减慢查询的才会生效。这样可以防止滚动超时。
_reindex可用于使用重命名的字段构建索引的副本。假设您创建一个包含如下所示的文档的索引：
POST test/test/1?refresh
{
"text": "words words",
"flag": "foo"
}
但是你不喜欢这个flag名称，而是要用tag替换它。 _reindex可以为您创建其他索引：
POST _reindex
{
"source": {
"index": "test"
},
"dest": {
"index": "test2"
},
"script": {
"inline": "ctx._source.tag = ctx._source.remove(\"flag\")"
}
}
现在你可以得到新的文件：
GET test2/test/1
它看起来像：
{
"found": true,
"_id": "1",
"_index": "test2",
"_type": "test",
"_version": 1,
"_source": {
"text": "words words",
"tag": "foo"
}
}
或者你可以通过tag进行任何你想要的搜索。
重建索引支持滚动切片，您可以相对轻松地手动并行化处理：
POST _reindex
{
"source": {
"index": "twitter",
"slice": {
"id": 0,
"max": 2
}
},
"dest": {
"index": "new_twitter"
}
}
POST _reindex
{
"source": {
"index": "twitter",
"slice": {
"id": 1,
"max": 2
}
},
"dest": {
"index": "new_twitter"
}
}
您可以通过以下方式验证：
GET _refresh
POST new_twitter/_search?size=0&filter_path=hits.total
其结果一个合理的total像这样：
{
"hits": {
"total": 120
}
}
你还可以让重建索引使用切片的_uid来自动并行的滚动切片。
POST _reindex?slices=5&refresh
{
"source": {
"index": "twitter"
},
"dest": {
"index": "new_twitter"
}
}
您可以通过以下方式验证：
POST new_twitter/_search?size=0&filter_path=hits.total
其结果一个合理的total像这样：
{
"hits": {
"total": 120
}
}
将slices添加到_reindex中可以自动执行上述部分中使用的手动过程，创建子请求，这意味着它有一些怪癖：
slices请求任务的“子”任务。slices请求任务的状态只包含已完成切片的状态。slices的重置节流阀请求将按相应的重新计算未完成的子请求。slices的取消请求将取消每个子请求。slices的性质，每个子请求将不会获得完全均匀的文档部分。所有文件都将被处理，但有些片可能比其他片大。预期更大的切片可以有更均匀的分布。slices请求的request_per_second和size的参数相应的分配给每个子请求。结合上述关于分布的不均匀性，您应该得出结论，使用切片大小可能不会导致正确的大小文档为_reindex。在这一点上，我们围绕要使用的slices数量提供了一些建议（比如手动并行化时，切片API中的max参数）：
500就能造成相当大的CPU抖动。slices数量线性扩展。reindexing的集群。您可以使用_reindex与Painless组合来重新每日编制索引，以将新模板应用于现有文档。 假设您有由以下文件组成的索引：
PUT metricbeat-2016.05.30/beat/1?refresh
{"system.cpu.idle.pct": 0.908}
PUT metricbeat-2016.05.31/beat/1?refresh
{"system.cpu.idle.pct": 0.105}
metricbeat-*索引的新模板已经加载到Elaticsearch中，但它仅适用于新创建的索引。Painless可用于重新索引现有文档并应用新模板。
下面的脚本从索引名称中提取日期，并创建一个附带有-1的新索引。来自metricbeat-2016.05.31的所有数据将重新索引到metricbeat-2016.05.31-1。
POST _reindex
{
"source": {
"index": "metricbeat-*"
},
"dest": {
"index": "metricbeat"
},
"script": {
"lang": "painless",
"inline": "ctx._index = 'metricbeat-' + (ctx._index.substring('metricbeat-'.length(), ctx._index.length())) + '-1'"
}
}
来自上一个度量索引的所有文档现在可以在*-1索引中找到。
GET metricbeat-2016.05.30-1/beat/1
GET metricbeat-2016.05.31-1/beat/1
以前的方法也可以与更改字段的名称一起使用，以便将现有数据加载到新索引中，但如果需要，还可以重命名字段。
Reindex可用于提取用于测试的索引的随机子集：
POST _reindex
{
"size": 10,
"source": {
"index": "twitter",
"query": {
"function_score" : {
"query" : { "match_all": {} },
"random_score" : {}
}
},
"sort": "_score" //①
},
"dest": {
"index": "random_twitter"
}
}
① Reindex默认按_doc排序，所以random_score不会有任何效果，除非您将排序重写为_score。