文章目錄

• • 1. Reindex API簡介
  • 2. 從遠(yuǎn)程集群重建索引
  • 3. URL參數(shù)
  • 4. 響應(yīng)體
  • 5. 配合Task API使用
  • • 1. 查找任務(wù)
    • 2. 配合取消任務(wù)API使用
    • 3. 重置節(jié)流閥
    • 4. 修改字段名
  • 6. 使用slice并行執(zhí)行
  • • 1. 手動(dòng)切片
    • 2. 自動(dòng)切片
    • 3. 挑選slice的數(shù)量
  • 8. index name 帶有日志的索引的重建
  • 提取索引的隨機(jī)子集

1. Reindex API簡介

Reindex不會(huì)嘗試創(chuàng)建目標(biāo)索引。它不會(huì)復(fù)制源索引的設(shè)置信息。您應(yīng)該在運(yùn)行_reindex操作之前創(chuàng)建目標(biāo)索引，包括設(shè)置mapping,shard,replica_num等。

_reindex的最基本形式只是將文檔從一個(gè)索引復(fù)制到另一個(gè)索引。下面將文檔從twitter索引復(fù)制到new_twitter索引中：

POST _reindex {"source": {"index": "twitter"},"dest": {"index": "new_twitter"} }

這將會(huì)返回類似以下的信息：

{"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獲取源索引的snapshot，但其目標(biāo)索引必須是不同的索引，因此不會(huì)發(fā)生版本沖突。 dest元素可以像index API一樣進(jìn)行配置基于樂觀鎖的并發(fā)控制。如果將version_type 空著（像上面一樣）或?qū)ersion_type設(shè)置為internal,則Elasticsearch強(qiáng)制性的將文檔轉(zhuǎn)儲(chǔ)到目標(biāo)中，覆蓋具有相同類型和ID的任何內(nèi)容：

POST _reindex {"source": {"index": "twitter"},"dest": {"index": "new_twitter","version_type": "internal"} }

將version_type設(shè)置為external將導(dǎo)致Elasticsearch從源doc中攜帶version，如果target index中沒有這個(gè)doc會(huì)創(chuàng)建該doc,反之target index中的對應(yīng)的version小于當(dāng)前verison才會(huì)更新。

POST _reindex {"source": {"index": "twitter"},"dest": {"index": "new_twitter","version_type": "external"} }

設(shè)置op_type為create將導(dǎo)致_reindex僅在目標(biāo)索引中創(chuàng)建缺少的文檔。所有存在的文檔將導(dǎo)致版本沖突：

POST _reindex {"source": {"index": "twitter"},"dest": {"index": "new_twitter","op_type": "create"} }

默認(rèn)情況下，version 沖突將中止_reindex進(jìn)程，但您可以通過請求體設(shè)置"conflict":"proceed"來在沖突時(shí)進(jìn)行計(jì)數(shù)：

POST _reindex {"conflicts": "proceed","source": {"index": "twitter"},"dest": {"index": "new_twitter","op_type": "create"} }

您可以通過向source添加type或添加query來限制文檔。下面會(huì)將kimchy發(fā)布的tweet復(fù)制到new_twitter中：

POST _reindex {"source": {"index": "twitter","query": {"term": {"user": "kimchy"}}},"dest": {"index": "new_twitter"} }

source中的index和type都可以是一個(gè)列表，允許您在一個(gè)請求中從大量的來源進(jìn)行復(fù)制。下面將從twitter和blog索引中的tweet和post類型中復(fù)制文檔。它也包含twitter索引中post類型以及blog索引中的tweet類型。如果你想更具體，你將需要使用query。它也沒有努力處理ID沖突。目標(biāo)索引將保持有效，但由于迭代順序定義不正確，預(yù)測哪個(gè)文檔可以保存下來是不容易的。

POST _reindex {"source": {"index": ["twitter", "blog"]},"dest": {"index": "all_together"} }

還可以通過設(shè)置大小限制處理的文檔的數(shù)量。下面只會(huì)將單個(gè)文檔從twitter復(fù)制到new_twitter：

POST _reindex {"size": 1,"source": {"index": "twitter"},"dest": {"index": "new_twitter"} }

如果你想要從twitter索引獲得一個(gè)特定的文檔集合你需要排序。排序使?jié)L動(dòng)效率更低，但在某些情況下它是值得的。如果可能，更喜歡更多的選擇性查詢size和sort。這將從twitter復(fù)制10000個(gè)文檔到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不同，腳本允許修改文檔的元數(shù)據(jù)。此示例修改了源文檔的版本：

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中一樣，您可以設(shè)置ctx.op來更改在目標(biāo)索引上執(zhí)行的操作：

noop: 設(shè)置 ctx.op = “noop” 。如果你的腳本并沒有對原來的doc做任何更改。這將導(dǎo)致 reindex 忽略該doc。這將在響應(yīng)的 noop 中被展示。

delete: 設(shè)置ctx.op = “delete”，如果你的腳本如此設(shè)定，target index中的該doc會(huì)被被刪除。這將在響應(yīng)的 deleted 中被展示。

也就是說使用update 和 update_by_query 的api是有能力刪除doc的

設(shè)置 ctx.op成別的值會(huì)報(bào)錯(cuò)。設(shè)置任何其它領(lǐng)域中 ctx 也會(huì)報(bào)錯(cuò)。

下面的字段都是你可以在script中改變的，但是在你決定改變之前請仔細(xì)評估可能帶來的影響

_id _type _index _version _routing _parent

將_version設(shè)置為null或從ctx中移除version相關(guān)操作就像在索引請求中不發(fā)送版本一樣。這將導(dǎo)致目標(biāo)索引中的文檔被覆蓋，無論目標(biāo)版本或_reindex請求中使用的版本類型如何。

默認(rèn)情況下，如果_reindex看到具有routing的doc，則發(fā)送bulk request的時(shí)候routing將被保留，可以修改routing的值
在dest部分可以將routing字段設(shè)置為一下的值

keep: 將批量請求的每個(gè)匹配項(xiàng)的路由設(shè)置為匹配上的路由。默認(rèn)值。就是如果原文檔有custom routing就用源文檔的，沒有就滅有

discard: 丟棄源文檔的routing

=${某些文本}: 將批量請求的每個(gè)匹配項(xiàng)的路由設(shè)置為=之后的文本。
例如，您可以使用以下請求將source索引的所有公司名稱為cat的文檔復(fù)制到路由設(shè)置為cat的dest索引。

POST _reindex {"source": {"index": "source","query": {"match": {"company": "cat"}}},"dest": {"index": "dest","routing": "=cat"} }

默認(rèn)情況下，_reindex批量滾動(dòng)處理大小為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"} }

2. 從遠(yuǎn)程集群重建索引

Reindex支持從遠(yuǎn)程Elasticsearch群集重建索引：

這個(gè)非常適合es的跨版本升級(jí)數(shù)據(jù)遷移工作。

POST _reindex {"source": {"remote": {"host": "http://otherhost:9200","username": "user","password": "pass"},"index": "source","query": {"match": {"test": "data"}}},"dest": {"index": "dest"} }

host參數(shù)必須包含scheme，host和port（例如 https：// otherhost:9200）。用戶名和密碼參數(shù)是可選的，當(dāng)它們存在時(shí)，索引將使用基本認(rèn)證連接到遠(yuǎn)程Elasticsearch節(jié)點(diǎn)。使用基本認(rèn)證時(shí)請務(wù)必使用https，密碼將以純文本格式發(fā)送。

必須在elasticsearch.yaml中使用reindex.remote.whitelist屬性將遠(yuǎn)程主機(jī)明確列入白名單。它可以設(shè)置為允許的遠(yuǎn)程host和port組合的逗號(hào)分隔列表（例如otherhost:9200,another:9200,127.0.10.:9200,localhost:）。白名單忽略了scheme ——僅使用主機(jī)和端口。

此功能應(yīng)適用于您可能找到的任何版本的Elasticsearch的遠(yuǎn)程群集。這應(yīng)該允許您從任何版本的Elasticsearch升級(jí)到當(dāng)前版本，通過從舊版本的集群重新建立索引。

要啟用發(fā)送到舊版本Elasticsearch的查詢，query參數(shù)將直接發(fā)送到遠(yuǎn)程主機(jī)，無需驗(yàn)證或修改。

從遠(yuǎn)程服務(wù)器重新索引使用堆上緩沖區(qū)，該緩沖區(qū)默認(rèn)最大大小為100mb。如果遠(yuǎn)程索引包含非常大的文檔，則需要使用較小的批量。下面的示例將批次大小設(shè)置為10，這非常小。

POST _reindex {"source": {"remote": {"host": "http://otherhost:9200"},"index": "source","size": 10,"query": {"match": {"test": "data"}}},"dest": {"index": "dest"} }

也可以使用socket_timeout字段在遠(yuǎn)程連接上設(shè)置socket的讀取超時(shí)，并使用connect_timeout字段設(shè)置連接超時(shí)。兩者默認(rèn)為三十秒。此示例將套接字讀取超時(shí)設(shè)置為一分鐘，并將連接超時(shí)設(shè)置為十秒：

POST _reindex {"source": {"remote": {"host": "http://otherhost:9200","socket_timeout": "1m","connect_timeout": "10s"},"index": "source","query": {"match": {"test": "data"}}},"dest": {"index": "dest"} }

3. URL參數(shù)

除了標(biāo)準(zhǔn)參數(shù)像pretty之外，“Reindex API”還支持refresh、wait_for_completion、wait_for_active_shards、timeout以及requests_per_second。

當(dāng)請求完成時(shí)，發(fā)送 refresh將更新索引中的所有分片。這與索引index API 的 refresh 參數(shù)不同，index api只會(huì)refresh收到請求的shard。

如果請求包含wait_for_completion=false，那么Elasticsearch將執(zhí)行一些預(yù)檢檢查、啟動(dòng)請求、然后返回一個(gè)任務(wù)，可以與Tasks API一起使用來取消或獲取任務(wù)的狀態(tài)。Elasticsearch還將以.tasks/task/${taskId}作為文檔創(chuàng)建此任務(wù)的記錄。這是你可以根據(jù)是否合適來保留或刪除它。當(dāng)你完成它時(shí)，刪除它可以讓Elasticsearc

wait_for_active_shards控制在繼續(xù)請求之前必須有多少個(gè)分片必須處于活動(dòng)狀態(tài)，詳見這里。timeout控制每個(gè)寫入請求等待不可用分片變成可用的時(shí)間。兩者都能正確地在Bulk API中工作。

requests_per_second可以設(shè)置為任何正數(shù)（1.4，6，1000等），來作為“delete-by-query”每秒請求數(shù)的節(jié)流閥數(shù)字，或者將其設(shè)置為-1以禁用限制。節(jié)流是在批量批次之間等待，以便它可以操縱滾動(dòng)超時(shí)。等待時(shí)間是批次完成的時(shí)間與request_per_second * requests_in_the_batch的時(shí)間之間的差異。由于分批處理沒有被分解成多個(gè)批量請求，所以會(huì)導(dǎo)致Elasticsearch創(chuàng)建許多請求，然后等待一段時(shí)間再開始下一組。這是“突發(fā)”而不是“平滑”。默認(rèn)值為-1。在集群本省的任務(wù)比較重的情況下建議開啟限流，以減少對集群資源的使用。

throttle的計(jì)算方式是，每秒處理requests_per_second 個(gè)request,假如我們設(shè)置requests_per_second=500,寫1000個(gè)需要0.5s，則等待時(shí)間是

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

默認(rèn)沒有限流

4. 響應(yīng)體

JSON響應(yīng)類似如下：

{"took" : 639,"updated": 0,"created": 123,"batches": 1,"version_conflicts": 2,"retries": {"bulk": 0,"search": 0}"throttled_millis": 0,"failures" : [ ] }

took: 從整個(gè)操作的開始到結(jié)束的毫秒數(shù)。
updated: 成功更新的文檔數(shù)。
upcreateddated: 成功創(chuàng)建的文檔數(shù)。
batches: 通過查詢更新的滾動(dòng)響應(yīng)數(shù)量。
version_conflicts: 根據(jù)查詢更新時(shí)，版本沖突的數(shù)量。
retries: 根據(jù)查詢更新的重試次數(shù)。bluk 是重試的批量操作的數(shù)量，search 是重試的搜索操作的數(shù)量。
throttled_millis: 請求休眠的毫秒數(shù)，與requests_per_second一致。
failures: 失敗的索引數(shù)組。如果這是非空的，那么請求因?yàn)檫@些失敗而中止。請參閱 conflicts 來如何防止版本沖突中止操作。

5. 配合Task API使用

您可以使用Task API獲取任何正在運(yùn)行的重建索引請求的狀態(tài)：

1. 查找任務(wù)

GET _tasks?detailed=true&actions=*/update/byquery 響應(yīng)會(huì)類似如下：{"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" : ""}}}} }

① 此對象包含實(shí)際狀態(tài)。它就像是響應(yīng)json，重要的添加total字段。 total是重建索引希望執(zhí)行的操作總數(shù)。您可以通過添加的updated、created和deleted的字段來估計(jì)進(jìn)度。當(dāng)它們的總和等于total字段時(shí)，請求將完成。

使用任務(wù)id可以直接查找任務(wù)：

GET /_tasks/taskId:1

這個(gè)API的優(yōu)點(diǎn)是它與wait_for_completion=false集成，以透明地返回已完成任務(wù)的狀態(tài)。如果任務(wù)完成并且wait_for_completion=false被設(shè)置，那么它將返回results或error字段。此功能的成本是wait_for_completion=false在.tasks/task/${taskId}創(chuàng)建的文檔，由你自己刪除該文件。

2. 配合取消任務(wù)API使用

所有重建索引都能使用Task Cancel API取消：

POST _tasks/task_id:1/_cancel

可以使用上面的任務(wù)API找到task_id。

取消應(yīng)盡快發(fā)生，但可能需要幾秒鐘。上面的任務(wù)狀態(tài)API將繼續(xù)列出任務(wù)，直到它被喚醒取消自身。

3. 重置節(jié)流閥

request_per_second的值可以在通過查詢刪除時(shí)使用_rethrottle API更改：

POST _update_by_query/task_id:1/_rethrottle?requests_per_second=-1

可以使用上面的任務(wù)API找到task_id。

就像在_update_by_query API中設(shè)置它一樣，request_per_second可以是-1來禁用限制，或者任何十進(jìn)制數(shù)字，如1.7或12，以節(jié)制到該級(jí)別。加速查詢的會(huì)立即生效，但是在完成當(dāng)前批處理之后，減慢查詢的才會(huì)生效。這樣可以防止?jié)L動(dòng)超時(shí)。

4. 修改字段名

_reindex可用于使用重命名的字段構(gòu)建索引的副本。假設(shè)您創(chuàng)建一個(gè)包含如下所示的文檔的索引：

POST test/_doc/1?refresh {"text": "words words","flag": "foo" }

但是你不喜歡這個(gè)flag名稱，而是要用tag替換它。 _reindex可以為您創(chuàng)建其他索引：

POST _reindex {"source": {"index": "test"},"dest": {"index": "test2"},"script": {"inline": "ctx._source.tag = ctx._source.remove(\"flag\")"} }

現(xiàn)在你可以get得到新的文件：

GET test2/_doc/1

它看起來像：

{"found": true,"_id": "1","_index": "test2","_type": "_doc","_version": 1,"_seq_no": 44,"_primary_term": 1,"_source": {"text": "words words","tag": "foo"} }

或者你可以通過tag進(jìn)行任何你想要的搜索。

6. 使用slice并行執(zhí)行

1. 手動(dòng)切片

重建索引支持滾動(dòng)切片，您可以相對輕松地手動(dòng)并行化處理：

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"} }

您可以通過以下方式驗(yàn)證：

GET _refresh POST new_twitter/_search?size=0&filter_path=hits.total

其結(jié)果一個(gè)合理的total像這樣：

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

2. 自動(dòng)切片

你還可以讓重建索引使用切片的_uid來自動(dòng)并行的滾動(dòng)切片。

POST _reindex?slices=5&refresh {"source": {"index": "twitter"},"dest": {"index": "new_twitter"} }

您可以通過以下方式驗(yàn)證：

POST new_twitter/_search?size=0&filter_path=hits.total

其結(jié)果一個(gè)合理的total像這樣：

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

將slices添加到_reindex中可以自動(dòng)執(zhí)行上述部分中使用的手動(dòng)過程，創(chuàng)建子請求，這意味著它有一些怪癖：

您可以在Task API中看到這些請求。這些子請求是具有slices請求任務(wù)的“子”任務(wù)。

獲取slices請求任務(wù)的狀態(tài)只包含已完成切片的狀態(tài)。

這些子請求可以單獨(dú)尋址，例如取消和重置節(jié)流閥。

slices的重置節(jié)流閥請求將按相應(yīng)的重新計(jì)算未完成的子請求。

slices的取消請求將取消每個(gè)子請求。

由于slices的性質(zhì)，每個(gè)子請求將不會(huì)獲得完全均勻的文檔部分。所有文件都將被處理，但有些片可能比其他片大。預(yù)期更大的切片可以有更均勻的分布。

帶有slices請求的request_per_second和size的參數(shù)相應(yīng)的分配給每個(gè)子請求。結(jié)合上述關(guān)于分布的不均勻性，您應(yīng)該得出結(jié)論，使用size 參數(shù)在slice中有可能刪除的并不是完全準(zhǔn)確的想要?jiǎng)h除的數(shù)據(jù)量。

每個(gè)子請求都會(huì)獲得源索引的略有不同的快照，盡管這些都是大致相同的時(shí)間。

3. 挑選slice的數(shù)量

如果使用auto模式，es默認(rèn)會(huì)選擇合適的slice數(shù)量
如果是主觀的設(shè)置slice的數(shù)量或者是手動(dòng)執(zhí)行slice，下面有一些建議。

不要使用大的數(shù)字，500就能造成相當(dāng)大的CPU抖動(dòng)。
在源索引中使用完全相同的分片是從查詢性能的角度來看效率最高的。
索引性能應(yīng)在可用資源之間以slices數(shù)量線性擴(kuò)展。
索引或查詢性能是否支配該流程取決于許多因素，如正在重建索引的文檔和進(jìn)行reindexing的集群。

8. index name 帶有日志的索引的重建

您可以使用_reindex與Painless組合來重新每日編制索引，以將新模板應(yīng)用于現(xiàn)有文檔。 假設(shè)您有由以下文件組成的索引：

PUT metricbeat-2016.05.30/_doc/1?refresh {"system.cpu.idle.pct": 0.908} PUT metricbeat-2016.05.31/_doc/1?refresh {"system.cpu.idle.pct": 0.105}

metricbeat-*索引的新模板已經(jīng)加載到Elaticsearch中，但它僅適用于新創(chuàng)建的索引。Painless可用于重新索引現(xiàn)有文檔并應(yīng)用新模板。

下面的腳本從索引名稱中提取日期，并創(chuàng)建一個(gè)附帶有-1的新索引。來自metricbeat-2016.05.31的所有數(shù)據(jù)將重新索引到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'"} }

來自上一個(gè)度量索引的所有文檔現(xiàn)在可以在*-1索引中找到。

GET metricbeat-2016.05.30-1/beat/1
GET metricbeat-2016.05.31-1/beat/1
以前的方法也可以與更改字段的名稱一起使用，以便將現(xiàn)有數(shù)據(jù)加載到新索引中，但如果需要，還可以重命名字段。

提取索引的隨機(jī)子集

Reindex可用于提取用于測試的索引的隨機(jī)子集：

POST _reindex {"size": 10,"source": {"index": "twitter","query": {"function_score" : {"query" : { "match_all": {} },"random_score" : {}}},"sort": "_score" //①},"dest": {"index": "random_twitter"} }

① Reindex默認(rèn)按_doc排序，所以random_score不會(huì)有任何效果，除非您將排序重寫為_score。

總結(jié)

以上是生活随笔為你收集整理的11.reindex操作的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。