赞
踩
目录
reindex 为 ES 5.X 版本之后提供的数据迁移功能,不需要额外安装,支持同集群索引迁移和跨集群索引迁移。
使用 reindex,要注意两点:
基础使用命令:
- POST _reindex
- {
- "source": {
- "index": "old_index"
- },
- "dest": {
- "index": "new_index"
- }
- }
说明:"version_type": "internal",internal表示内部的,省略version_type或version_type设置为 internal 将导致 Elasticsearch 盲目地将文档转储到目标中,覆盖任何具有相同类型和 ID 的文件。
这也是最常见的重建方式。
- POST _reindex
- {
- "source": {
- "index": "twitter"
- },
- "dest": {
- "index": "new_twitter",
- "version_type": "internal"
- }
- }
说明:"version_type": "external",external表示外部的,将 version_type 设置为 external 将导致 Elasticsearch 保留源中的版本,创建任何丢失的文档,并更新目标索引中版本比源索引中版本旧的任何文档。
id不存在的文档会直接更新;id存在的文档会先判断版本号,只会更新版本号旧的文档。
- POST _reindex
- {
- "source": {
- "index": "twitter"
- },
- "dest": {
- "index": "new_twitter",
- "version_type": "external"
- }
- }
要创建的 op_type 设置将导致 _reindex 仅在目标索引中创建丢失的文档,所有存在的文档都会引起版本冲突。
只要两个索引中存在id相同的记录,就会引起版本冲突。
- POST _reindex
- {
- "source": {
- "index": "twitter"
- },
- "dest": {
- "index": "new_twitter",
- "op_type": "create"
- }
- }
默认情况下,版本冲突会中止 _reindex 进程。 “冲突”请求正文参数可用于指示 _reindex 继续处理有关版本冲突的下一个文档。 需要注意的是,其他错误类型的处理不受“冲突”参数的影响。
当"conflicts": "proceed"在请求正文中设置时,_reindex 进程将继续处理版本冲突并返回遇到的版本冲突计数。
- POST _reindex
- {
- "conflicts": "proceed",
- "source": {
- "index": "twitter"
- },
- "dest": {
- "index": "new_twitter",
- "op_type": "create"
- }
- }
- POST _reindex
- {
- "source": {
- "index": "twitter",
- "query": {
- "term": {
- "user": "kimchy"
- }
- }
- },
- "dest": {
- "index": "new_twitter"
- }
- }
源中的索引可以是一个列表,允许您在一个请求中从多个源中复制。 这将从 twitter 和 blog 索引中复制文档:
- POST _reindex
- {
- "source": {
- "index": ["twitter", "blog"]
- },
- "dest": {
- "index": "all_together"
- }
- }
-
- 也支持*号来匹配多个索引。
-
- POST _reindex
- {
- "source": {
- "index": "twitter*"
- },
- "dest": {
- "index": "all_together"
- }
- }

通过设置size大小来限制处理文档的数量。
- POST _reindex
- {
- "size": 10000,
- "source": {
- "index": "twitter",
- "sort": { "date": "desc" }
- },
- "dest": {
- "index": "new_twitter"
- }
- }
注意:要保证源索引与目的索引的表结构信息一致,否则可能导致源索引与目的索引字段类型等信息不一致
例如:1、查询出源索引的表结构信息,并根据此表结构提前在目的集群中创建出目的索引
2、若源索引有对应的索引模版,可提前将该索引模版在目的集群中创建出
在目的 es 集群中配置上源 es 集群的白名单信息
- vim elasticsearch.yml
- # 在目的集群的elasticsearch.yml文件中增加源es集群的白名单配置
- reindex.remote.whitelist: “otherhost:9200”
- POST _reindex?wait_for_completion=false
- {
- "source": {
- "remote": {
- "host": "http://otherhost:9200",
- "username": "user",
- "password": "password"
- },
- "size":5000
- "index": "source"
- },
- "dest": {
- "index": "dest"
- }
- }
说明:从源索引中随机取10条数据到新索引中。
- POST _reindex
- {
- "size": 10,
- "source": {
- "index": "twitter",
- "query": {
- "function_score" : {
- "query" : { "match_all": {} },
- "random_score" : {}
- }
- },
- "sort": "_score"
- },
- "dest": {
- "index": "random_twitter"
- }
- }

- 原索引
- POST test/_doc/1?refresh
- {
- "text": "words words",
- "flag": "foo"
- }
-
- 重建索引,将原索引中的flag字段重命名为tag字段。
-
- POST _reindex
- {
- "source": {
- "index": "test"
- },
- "dest": {
- "index": "test2"
- },
- "script": {
- "source": "ctx._source.tag = ctx._source.remove(\"flag\")"
- }
- }
-
- 结果:
- 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"
- }
- }

es中的请求超时时间默认是1分钟,当重建索引的数据量太大时,经常会出现超时。这种情况可以增大超时时间,也可以添加wait_for_completion=false参数将请求转为异步任务。
- POST _reindex?wait_for_completion=false
- {
- "source": {
- "index": "twitter"
- },
- "dest": {
- "index": "new_twitter"
- }
- }
常规的如果我们只是进行少量的数据迁移利用普通的reindex就可以很好的达到要求,但是当我们发现我们需要迁移的数据量过大时,我们会发现reindex的速度会变得很慢。数据量几十个G的场景下,elasticsearch reindex速度太慢,从旧索引导数据到新索引,当前最佳方案是什么?
原因分析:
reindex的核心做跨索引、跨集群的数据迁移。
慢的原因及优化思路无非包括:
可行方案:
默认情况下 _reindex 使用 1000 的滚动批次。可以使用源元素source中的 size 字段更改批次大小:
- POST _reindex
- {
- "source": {
- "index": "source",
- "size": 5000
- },
- "dest": {
- "index": "dest"
- }
- }
Reindex 支持 Sliced Scroll 来并行化重新索引过程。 这种并行化可以提高效率并提供一种将请求分解为更小的部分的便捷方式。
每个Scroll请求,可以分成多个Slice请求,可以理解为切片,各Slice独立并行,利用Scroll重建或者遍历要快很多倍。
slicing的设定分为两种方式:手动设置分片、自动设置分片。
自动设置分片如下:
- POST _reindex?slices=5&refresh
- {
- "source": {
- "index": "twitter"
- },
- "dest": {
- "index": "new_twitter"
- }
- }
slices大小设置注意事项:
1)slices大小的设置可以手动指定,或者设置slices设置为auto,auto的含义是:针对单索引,slices大小=分片数;针对多索引,slices=分片的最小值。
2)当slices的数量等于索引中的分片数量时,查询性能最高效。slices大小大于分片数,非但不会提升效率,反而会增加开销。
3)如果这个slices数字很大(例如500),建议选择一个较低的数字,因为过大的slices 会影响性能。
如果要进行大量批量导入,请考虑通过设置index.number_of_replicas来禁用副本:0。
主要原因在于:
- PUT /my_logs/_settings
- {
- "number_of_replicas": 1
- }
如果你的搜索结果不需要接近实时的准确性,考虑先不要急于索引刷新refresh。可以将每个索引的refresh_interval到30s。
如果正在进行大量数据导入,可以通过在导入期间将此值设置为-1来禁用刷新。完成后不要忘记重新启用它!
设置方法:
- PUT /my_logs/_settings
- { "refresh_interval": -1 }
translog默认的持久化策略为:request。这个非常影响 ES 写入速度。但是这样写操作比较可靠。如果系统可以接受一定概率的数据丢失(例如:数据写入主分片成功,尚未复制到副分片时,主机断电。由于数据既没有刷到Lucene,translog也没有刷盘,恢复时translog中没有这个数据,数据丢失),则调整translog持久化策略。
在每一个索引,删除,更新或批量请求之后是否进行fsync和commit操作。此设置接受以下参数:
- PUT /my_logs/_settings
- { "index.translog.durability": "async" }
GET _tasks?actions=*reindex*&detailed
GET /_tasks/W29Va7J_Tj--sUYS6fSWlg:280879028
其中task.status.total表示源数据总行数,task.status.created表示已同步的行数
POST _tasks/W29Va7J_Tj--sUYS6fSWlg:280879028/_cancel
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。