背景
因为ES所在机器，有会大量占用cpu和内存的软件，导致ES运行不稳定甚至无法响应的问题。我们对ES的服务进行了迁移。
迁移方法
我们使用的ES版本是2.3.3，现在已经更新到了5.x版本(当时5.6.1)。而且ES更新到5.x后，增加了很多。因此，我们也正好准备借这次迁移，将ES给升级了。
最初迁移和升级方法是基于官网资料，得出的方法如下：
- 在新环境安装相同2.3.3 ES集群。
- 数据迁移：使用的方法进行数据迁移
- 升级: 使用进行升级。
官网升级方法主要针对原来的ES集群进行升级，我们的需求就是在新的环境使用新版本。所以我们的想法：
- 直接在新环境搭建最新版本的ES集群(5.6.1)，
- 迁移数据。
这样用两步完成ES迁移和升级。
基于这个思路，找到了一些迁移工具：
-
。这个工具正好srcoll+bulk原理，进行数据迁移，该工具安装简单，解压即可使用。
scroll查询:es深度分页查询，基于http请求，可以查询索引下所有数据，不会有from+size不能大于1w的问题。
bulk请求:可以批量插入数据，是http请求。
-
.安装环境依赖npm。 说有不成功的，而且觉得安装比较麻烦，就弃了。
-
. 这个运行环境同样依赖npm。这个运行方式和elasticsearch-migration有些类似。但是相比较还是elasticsearch-migration安装简单。
经过对比分析Elasticsearch-Migration安装和使用都比较简单，最终选择了Elasticsearch-Migration。
Elasticsearch-Migration介绍
- elasticsearch-migration支持：多个版本间的数据迁移，使用scroll+bulk的接口原理。
| From | To |
|---|---|
| 1.x | 1.x |
| 1.x | 2.x |
| 1.x | 5.0 |
| 2.x | 1.x |
| 2.x | 2.x |
| 2.x | 5.0 |
| 5.0 | 1.x |
| 5.0 | 2.x |
| 5.0 | 5.0 |
我们此次迁移的版本正好在支持的列表里。同时也在测试环境进行验证。
- 在测试环境对迁移效率进行评估：测试数据： 46894/13s≈3600/s。每条数据有13个字段。线上数据：数据量39,390,354，大小：约13.7G，总共时间大约半小时。
-
安装和使用
elasticsearch-migration支持linux，windows等不同系统，下载解压后可以直接运行。使用示例
./esm -s -d -x index_name -w=5 -b=10 -c 10000
-w 表示线程数
-b 表示一次bulk请求数据大小，单位MB默认 5M
-c 一次scroll请求数量
[更详细参数可参考官网]
-
迁移过程还有进度条提示.
迁移步骤
方案确定好了，工具也有了，下面开始做迁移。
-
下载、安装、配置新的ES集群
（包括ElasticSearch.xml、jvm.options配置）。5.6.1Es的JVM参考包括最大/小内存(-Xms,-Xmx)，GC都可以在jvm.options进行配置，不需要加在es启动里了。
-
安装ES插件：（中文分词器），X-pack(5.x之前用X-pack,之前用Marvel)
-
迁移ES模板。
-
业务和数据迁移（迁移关键步骤）:
4.1 停止微信同步任务、关掉Logstash应用(廖XX)
4.2 同步旧ES集群数据到新ES集群（运维-王XX），确认数据同步没有问题（廖XX，测试-魏XX），主要同步微信数据
4.3 发布新代码分支，确认业务（廖xx、测试-魏xx）
4.4 开启确认微信同步任务(测试-魏xx)，修改logstash配置重新启动（廖xx）
这一步涉及到多个组之间的合作，所以将迁移过程不同的同事对应工作内容都列出来，这样在实际过程中，大家能有清晰的过程，减少迁移过程的沟通成本。
批量索引迁移脚本：
迁移以srcIndex1,scrIndex2为前缀的索引#!/bin/sh dir="/tmp/es/es/bin/linux64"cd $diresindex=`curl -s 'http://10.10.10.10:9204/_cat/indices' | grep -e 迁移srcIndex1* -e scrIndex2* | awk '{print $3}'`#echo $esindex for i in $esindex;do ./esm -s http://10.10.10.10:9204 -x $i -d http://10.10.10.11:9204 -x $i -w=5 -b=10 -c 10000done[脚本贡献者：王振伟] ES升级过程的注意点、问题
- 因为ELK中Kibana版本依赖ES的版本的，在ES升级同时，Kibana 也需要升级。
- 有的时候可能不是最新的就是最合适的，在选择新版本过程中需要进行评估：比如插件的支持，尤其是第三方插件。我们用了IK中文分词插件，当时ES最新版的是5.6.2，而IK最新版的还只支持到5.6.1.
- elasticsearch-migration只会插入数据，不会更新数据。所以在第四步做业务迁移时，若是迁移数据量较大，可以考虑先将迁移可能会被修改数据，对于其他确定不会被修改的数据，可以等业务迁移完成之后，再进行。
- IK配置文件：2.3.3版本IK的配置是在ES安装目录plugin下面，5.6.1版本是在ES安装目录的config下。
- 5.x string分为text和keyword两种数据类型。
- 因为5.x对一些查询（比如filter查询）和聚合查询进行的调整，在业务应用迁移之前，需要在测试环境下先对原有业务进行回归测试。目前我发现的有：
- 5.x版本,term聚合查询时，聚合中size不能为0，否则会报错。
- 5.x 对于filter查询结构进行调整，回归业务测试时需要注意。
总结
数据迁移过程其实并没有使用很高深的技术，关键还是在安排好迁移过程中每一个步骤：包括迁移前，新集群的测试、业务测试，尤其业务迁移过程中，不同组之间的配合安排。
另外，在安装新应用时候，需要确认该环境，避免和已有其他应用在CPU、内存等使用上是的冲突，以免影响软件运行的稳定性。
转自【http://tech.lede.com/2017/10/25/rd/server/ElasticSearch_migration_upgrade/】