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: