Elasticsearch1.7.3升级到2.4.2记录

咱们用ELK作日志分析系统，Elasticsearch1.7.3运行了近一年，最近已经将一个集群升级到ES5.1.1，可是遇到问题比较多。因此将另外一个集群升级到社区推荐比较稳定的2.4.2。为了便于升级管理，操做都是用ansible来统一执行。

一：中止monit守护进程

#集群的全部logstash、es进程都是由monit监控守护，先中止监控守护。感兴趣monit的能够看我另外一篇文章《使用M/Monit进行可视化集中进程管理》

$ ansible elksjs -m shell -a '/opt/monit/bin/monit -c /opt/monit/conf/monitrc unmonitor all'

二：中止es集群写入

#因为前端顶了kafka集群，因此后端中止写入，数据会堆积在kafka中。集群启动后继续消费。数据不会丢失。

$ ansible elksjs -m shell -a '/etc/init.d/logstash start'

三:中止logstash写入后，同步副本commitd

#和linux命令sync的相似，停机前将内存中数据刷到磁盘中。

$ curl -XPOST localhost:9200/_flush/synced

四:停机前禁止分片分配

#禁止分片分配，防止集群启动后，某些节点没有及时加入而致使数据在集群中分配均衡，增长负载。应该等全部节点加入后，再开启分片分配。

$ curl -XPUT  localhost:9200/_cluster/settings -d '{"transient":{"cluster.routing.allocation.enable": "none"}}'

五：中止es

#中止全部es的节点。

$ ansible elksjs -m shell -a '/etc/init.d/elasticsearch stop'

六：卸载es老版本

#卸载全部es的安装包

$ ansible elksjs -m shell -a 'rpm -e elasticsearch-1.7.3-1'

七：安装新包

#安装新的es2.4.2安装包

ansible elksjs -m shell -a 'wget https://download.elastic.co/elasticsearch/release/org/elasticsearch/distribution/rpm/elasticsearch/2.4.2/elasticsearch-2.4.2.rpm -P /opt' 
ansible elksjs -m shell -a 'rpm -iv /opt/elasticsearch-2.4.2.rpm'

八：恢复配置文件和启动文件

#作这一步的前提是本次升级配置文件没有变化，1.7.3和2.4.2的配置变化不大，个人配置中都适配2.4.2版本，因此直接用原配置了。稍后再作优化和调整。若是有变化，请更新配置文件。

$ ansible elksjs -m shell -a 'cd /etc/init.d/ &&rm elasticsearch && mv elasticsearch.rpmsave elasticsearch'

$ ansible elksjs -m shell -a 'cd  /etc/elasticsearch/&& rm -rf elasticearch.yml &&mv elasticsearch.yml.rpmsave elasticsearch.yml'

九：修改数据目录属主

#因为卸载es安装包的时候也删除了es用户，又新建了es用户，因此要从新给es的data目录属主改为elasticsearch。

$ ansible elksjs -m shell -a 'chown -R elasticsearch.elasticsearch /data/elk/es'
$ ansible elksjs -m shell -a 'chown -R elasticsearch.elasticsearch /data/es'

十：启动elasticsearch

#启动es进程，这一步没有报错就万事大吉了，事实上不是。。。经历了屡次报错，屡次回滚到老版本，调整后终于升级成功了。

ansible elksjs -m shell -a '/etc/init.d/elasticsearch start'

十一：检查集群是否健康

#集群启动后，经过下面来检查集群节点是否都加入集群，集群是否健康。事实上，个人五个master启动后自动加入集群，可是数据节点升级后启动时基本都在作索引升级操做。es2.x和es1.x对多目录索引路径的存放策略是不一样的。须要将全部的数据move一遍。等待时间很长。

$ curl localhost:9200/_cat/health?v
$ curl localhost:9200/_cat/nodes?v

十二：集群启动后启动分片分配

#等全部节点都加入集群后，能够开启分片分配

curl -XPUT  localhost:9200/_cluster/settings -d '{"transient": {"cluster.routing.allocation.enable": "all"}}'

十三：下载新版本head和kopf插件

#以前1.X用的head插件和kopf-1.5发如今es2.4.2中都没法正常显示，只好卸载重装了，安装了新的版本。

$ wget https://codeload.github.com/mobz/elasticsearch-head/zip/master
$ wget https://codeload.github.com/lmenezes/elasticsearch-kopf/tar.gz/v2.1.2
$ tar xf elasticsearch-kopf-2.1.2.tar.gz
$ unzip elasticsearch-head-master.zip
$ mv elasticsearch-kopf-2.1.2 /usr/share/elasticsearch/plugins/kopf
$ mv elasticsearch-head-master /usr/share/elasticsearch/plugins/head

十四：更新kibana

#因为以前使用的是ES1.X，在2.x中已经再也不支持kibana3，可是因为有大量的索引页在kibana3上，以及长时间的用户习惯，还想使用kibana3。社区里有同窗改了kibana3的代码，支持了es2.X。因此又能够愉快的使用kibana3了。

$ wget  https://github.com/childe/kibana3-with-es2/zip/master
# 将kibana3-with-es2/src做为web目录便可

 # kibana4以前使用的是4.1.4可是启动后也出现报错。使用4.6版本正常

$ wget https://download.elastic.co/kibana/kibana/kibana-4.6.0-x86_64.rpm

---

升级过程当中遇到的问题

（1）：当设置bootstrap.mlockall: true时，启动es报警告Unknown mlockall error 0。

解决方法：设置为锁住内存大小无限制，linux命令：ulimit -l unlimited

（2）：升级后，启动es报错Failed to created node environment，缘由是卸载es包以后，es用户被删除。新安装的es包，建立了新的es用户。而原来的data目录属主仍是原来的id。因此新的es用户没有权限去读数据。致使没法启动。

[2016-07-24 19:19:16,280][ERROR][bootstrap                ] Exception

org.elasticsearch.ElasticsearchIllegalStateException: Failed to created node environment

data 

解决办法：chown -R elasticsearch.elasticsearch /data/elk/es

（3）：新的字段中不容许有.的存在，以前因为采用kv随机匹配产生了大量的随机字段，不少包含了.,因此没法升级

Starting elasticsearch: Exception in thread "main" java.lang.IllegalStateException: unable to upgrade the mappings for the index [logstash-adn-2016.07.02], reason: [Field name [adn_tabArticle.articleId] cannot contain '.']

Likely root cause: MapperParsingException[Field name [adn_tabArticle.articleId] cannot contain '.']

atorg.elasticsearch.index.mapper.object.ObjectMapper$TypeParser.parseProperties(ObjectMapper.java:278)

解决办法：注销kv切割字段，等待老索引过时再升级。

（4）：字段类型不一样致使es的mapping报错。以前因为output插件的判断不够严谨，致使packetbeat的部分数据写到logstash的索引中，在logstash索引中port字段出现了number和string两种类型，产生冲突，致使es没法升级。

unable to upgrade the mappings for the index [logstash-2016.12.12], reason: [mapper [port] cannot be changed from type [string] to [long]]。

解决办法：注从新写logstash的判断输出，等待冲突索引过时。

（5）：ES启动后，数据节点进行索引升级，可是发现不少已经删除的几个月前老索引也在升级操做，很是耗费时间。

解决办法：删除掉data目录下的无用的索引目录。

（6）：Kibana: This version of Kibana requires Elasticsearch ^1.4.4 on all nodes.

I found the following incompatible nodes in your cluster: Elasticsearch v2.4.2 @ undefined

解决办法：kiabna版本4.1.4与es2.4.2不匹配。更新到4.6.1正常使用。

（7）kibana4.6.1报错 Courier Fetch Error: unhandled courier request error: Authorization Exception

解决办法：注释掉 http.cors.enabled: