ElasticSearch集群迁移和升级总结

背景

由于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的接口原理。

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

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

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

2. 安装和使用

   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. 迁移过程还有进度条提示.
   

迁移步骤

方案肯定好了，工具也有了，下面开始作迁移。

1. 下载、安装、配置新的ES集群

   （包括ElasticSearch.xml、jvm.options配置）。5.6.1Es的JVM参考包括最大/小内存(-Xms,-Xmx)，GC均可以在jvm.options进行配置，不须要加在es启动里了。

2. 安装ES插件：IK（中文分词器），X-pack(5.x以前用X-pack,以前用Marvel)

3. 迁移ES模板。

4. 业务和数据迁移（迁移关键步骤）:

   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 $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、内存等使用上是的冲突，以避免影响软件运行的稳定性。

 

转自【http://tech.lede.com/2017/10/25/rd/server/ElasticSearch_migration_upgrade/】