在技术生活中，我们无时不刻在用着“迁移简化”思维，例如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

node.max_local_storage_nodes: 2

reindex.remote.whitelist: 127.0.0.1:9200

2.3.2的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版本，如果有分片和副本等参数需求也要加上

source：远程ElasticSearch信息

host：远程es的ip和port列表

socket_timeout：超时时间设置

connect_timeout：超时时间设置

index：源索引名称

size：批操作大小，修改大小可获取性能

query：满足条件的数据，全部迁移可去除该参数

dest.index：目标索引名称

实际生产中，索引较大，迁移时间可能会过长，这时候如果一直等待会出现请求超时的情况，所以我们可以执行后台任务，只需增加wait_for_completion参数即可，然后去查询_tasks/taskeid来查看请求状态。

至此，依靠ElasticSearch本身完成数据迁移的方法就完成了。

PS：除了文中提及的方法，还有很多工具可以去完成ElasticSearch数据迁移，比如logstash等，感兴趣的小伙伴可以留言，我们有机会下次探讨！