ElasticSearch之数据迁移
在技术生活中,我们无时不刻在用着“迁移简化”思维,例如ElasticSearch的迁移。
因为ES所在机器,会大量占用cpu和内存的软件,导致ES运行不稳定甚至无法响应的问题。这里我们无法直接打个响指,因为数据就像超级英雄,消失,是不行的!
于是我们需要对ES的服务进行迁移。本文就从2.3.2版本到6.3.1版本为例,为大家演示一下整个步骤。
首先看一下官方文档上给的方案
上面说的大概意思是2.x要升级到6.x,要先将2.x转到5.6,在从5.6转到6.x,因为2.x到6.x的索引不兼容。
下面我来演示一下我的步骤:
准备2.3.2版本和6.3.1版本的ElasticSearch
- 如果你想两个ElasticSearch安装在一台机器上需要加上限制单节点上可以开启的ES存储实例的个数的配置,默认一台机器上只能安装一个实例
node.max_local_storage_nodes: 2
- 在6.3.1的ElasticSearch上必须添加增加远程指定ip白名单的配置
reindex.remote.whitelist: 127.0.0.1:9200
2.3.2的ElasticSearch版本的准备工作
- 查询ElasticSearch保存的索引
- 查询索引mapping
6.3.1的ElasticSearch版本的准备工作
- 修改2.3.2版本每个索引的mapping,这个就有官网提到的索引不兼容的问题,string类型在6.3.1的ElasticSearch版本上被拆分成两种新的数据类型: text用于全文搜索的,而keyword用于关键词搜索。例如"desc":{"type":"string","index":"not_analyzed"}修改为"desc":{"type":"keyword"}
- 将修改后的mapping导入到6.3.1的ElasticSearch版本,如果有分片和副本等参数需求也要加上
执行_reindex的命令,进行数据迁移
source:远程ElasticSearch信息
host:远程es的ip和port列表
socket_timeout:超时时间设置
connect_timeout:超时时间设置
index:源索引名称
size:批操作大小,修改大小可获取性能
query:满足条件的数据,全部迁移可去除该参数
dest.index:目标索引名称
实际生产中,索引较大,迁移时间可能会过长,这时候如果一直等待会出现请求超时的情况,所以我们可以执行后台任务,只需增加wait_for_completion参数即可,然后去查询_tasks/taskeid来查看请求状态。
至此,依靠ElasticSearch本身完成数据迁移的方法就完成了。
PS:除了文中提及的方法,还有很多工具可以去完成ElasticSearch数据迁移,比如logstash等,感兴趣的小伙伴可以留言,我们有机会下次探讨!
ElasticSearch之数据迁移 - 开发专栏 - 恒生研究院
相关文章