背景

     因为ES所在机器，有会大量占用cpu和内存的软件，导致ES运行不稳定甚至无法响应的问题。我们对ES的服务进行了迁移。

迁移方法

    我们使用的ES版本是2.3.3，现在已经更新到了5.x版本(当时5.6.1)。而且ES更新到5.x后，增加了很多新特性和性能的优化。因此，我们也正好准备借这次迁移，将ES给升级了。

     最初迁移和升级方法是基于官网资料，得出的方法如下：

1. 在新环境安装相同2.3.3 ES集群。
2. 数据迁移：使用ES镜像导出和恢复的方法进行数据迁移
3. 升级: 使用ES官网介绍升级方法进行升级。

    官网升级方法主要针对原来的ES集群进行升级，我们的需求就是在新的环境使用新版本。所以我们的想法：

1. 直接在新环境搭建最新版本的ES集群(5.6.1)，
2. 迁移数据。

     这样用两步完成ES迁移和升级。

基于这个思路，找到了一些迁移工具：

1. elasticsearch-migration。这个工具正好srcoll+bulk原理，进行数据迁移，该工具安装简单，解压即可使用。

   scroll查询:es深度分页查询，基于http请求，可以查询索引下所有数据，不会有from+size不能大于1w的问题。

   bulk请求:可以批量插入数据，是http请求。

2. elasticsearch-dump.安装环境依赖npm。网上有人尝试 说有不成功的，而且觉得安装比较麻烦，就弃了。

3. Elasticsearch-Exporter. 这个运行环境同样依赖npm。这个运行方式和elasticsearch-migration有些类似，也不成功。但是相比较还是elasticsearch-migration安装简单。

经过对比分析Elasticsearch-Migration安装和使用都比较简单，最终选择了Elasticsearch-Migration。

Elasticsearch-Migration介绍

1. elasticsearch-migration支持：多个版本间的数据迁移，使用scroll+bulk的接口原理。

      我们此次迁移的版本正好在支持的列表里。同时也在测试环境进行验证。

     1、在测试环境对迁移效率进行评估：
                 测试数据： 46894/13s≈3600/s。每条数据有13个字段。
                 线上数据：数据量39,390,354，大小：约13.7G，总共时间大约半小时。

     2、安装和使用

                 下载地址：https://github.com/medcl/esm-abandoned/releases

                 elasticsearch-migration支持linux，windows等不同系统，下载解压后可以直接运行。使用示例

                ./esm -s http://192.168.1.x:9200 -d http://192.168.1.y:9200 -x index_name -w=5 -b=10 -c 10000

                      -w 表示线程数

                      -b 表示一次bulk请求数据大小，单位MB默认 5M

                      -c 一次scroll请求数量

     3、迁移过程还有进度条提示.

批量索引迁移脚本：

        迁移以srcIndex1,scrIndex2为前缀的索引

[code]#!/bin/sh

dir="/tmp/es/es/bin/linux64"
cd $dir

esindex=`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 10000

done

ES升级过程的注意点、问题

1. 因为ELK中Kibana版本依赖ES的版本的，在ES升级同时，Kibana 也需要升级。
2. 有的时候可能不是最新的就是最合适的，在选择新版本过程中需要进行评估：比如插件的支持，尤其是第三方插件。我们用了IK中文分词插件，当时ES最新版的是5.6.2，而IK最新版的还只支持到5.6.1.
3. elasticsearch-migration只会插入数据，不会更新数据。所以在第四步做业务迁移时，若是迁移数据量较大，可以考虑先将迁移可能会被修改数据，对于其他确定不会被修改的数据，可以等业务迁移完成之后，再进行。
4. IK配置文件：2.3.3版本IK的配置是在ES安装目录plugin下面，5.6.1版本是在ES安装目录的config下。
5. 5.x string分为text和keyword两种数据类型。
6. 因为5.x对一些查询（比如filter查询）和聚合查询进行的调整，在业务应用迁移之前，需要在测试环境下先对原有业务进行回归测试。目前我发现的有：
   5.x版本,term聚合查询时，聚合中size不能为0，否则会报错。
   • 5.x 对于filter查询结构进行调整，回归业务测试时需要注意。

总结

       数据迁移过程其实并没有使用很高深的技术，关键还是在安排好迁移过程中每一个步骤：包括迁移前，新集群的测试、业务测试，尤其业务迁移过程中，不同组之间的配合安排。

       另外，在安装新应用时候，需要确认该环境，避免和已有其他应用在CPU、内存等使用上是的冲突，以免影响软件运行的稳定性。