网易乐得技术团队

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

迁移步骤

方案确定好了,工具也有了,下面开始做迁移。

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