一、升級前的準備工做html
從Elasticsearch 的官方網站 https://www.elastic.co/downloads/elasticsearch 下載最新版本的Elasticsearch,爲了線上方便對數據包的管理,一版選擇 .gz.tar 格式或者 .zip 格式文件。node
解壓縮最新版本文件壓縮包到指定目錄,備份 config 目錄中的 elasticsearch.yml 文件(能夠簡單改名,爲elasticsearch.yml.bak便可)。而後複製當前版本Elasticsearch 中配置文件 elasticsearch.yml 文件的內容,到最新版本的 config 目錄中。linux
檢查系統中Java 環境是否正常,目前Elasticsearch 的版本必須使用Java 1.7.0及以上版本才能正常啓動 Elasticsearch。安全
修改 bin 目錄中 elasticsearch.in.sh 文件,關於Elasticsearch JVM 內存配置大小:網絡
此處能夠根據機器硬件配置狀況做出適當的調整,通常狀況下,此處的內存分配大小爲機器物理內存的一半,同時將 ES_MIN_MEM 與 ES_MAX_MEM 配置成相同的值,這樣的好處在於ES JVM大小固定,不會上下浮動,從實踐效果上看能夠提升 node 性能。負載均衡
檢查系統容許 Elasticsearch 打開的最大文件數curl
查看 /etc/security/limits.conf,若是沒有指定的話,默認是4096。這裏應該添加以下兩行:elasticsearch
這個值能夠根據須要適當的調整的更大。如此,當 Elasticsearch 中存在不少 index 的時候不會出現 Too many open files 的錯誤:ide
此外,因爲ES集羣通常都是在內部網絡環境中,且節點之間相互通訊使用的是 TCP 9300端口,節點與客戶端通訊則是經過 TCP 9200端口。所以檢查 iptalbes 以及SElinux 中是否開啓,以及肯定這些端口是否被綁定安全策略等等。性能
數據備份
在進行升級以前,咱們首先要作的就是備份好目前系統中已經存在數據,防止在升級的過程當中出現問題後能夠方便的恢復原有的數據。例如,在升級的過程當中,若是版本差異過大,可能會涉及到底層Lucene libraries的升級,這必將會影響到已存在的index數據,有時升級後的節點沒法加入原有版本的集羣中。
幸運的是Elasitcsearch的備份工做十分的簡單,備份將用到Elasticsearch的snapshot功能,關於備份和恢復的詳細過程我會單獨詳細闡述。
若是有必要的話,能夠在最後的上線以前能夠再作一次最後的測試,在測試以前,先修改Elasticsearch 中的配置文件,便是elasticsearch.yml 中的 cluster.name 參數的名稱,避免加入了線上集羣中。並利用 curl -XGET localhost:9201 來測試新版本的 Elasticsearch 進程是否正常。
curl -XGET localhost:9200
若是看到了以上內容,則代表新版本的Elasticsearch 能夠正常運行。接下來,就準備更換節點ES版本了。
二、集羣滾動升級
滾動升級(Rolling upgrade)
Rolling upgrade的備份過程可讓用戶在一個時間內只升級集羣中的某一個特定的節點。因爲Elasticsearch集羣具備很是優秀的容災機制,所以,在刪除集羣中的某一個節點時,數據並不會丟失,而是能夠由其他節點上的拷貝恢復。
不建議在一個集羣中長時間的運行多個版本的Elasticsearch實例,由於當刪除的節點恢復時,未來自多個版本實例的數據匯聚到同一個節點會有可能會致使節點沒法工做。
接下來來敘述Rolling upgrade升級的操做步驟:
關閉shard 的實時分配選項,這樣作的目的在於當集羣shutdown以後能夠快速的啓動。這個參數默認是開啓的,默認狀況下當實例啓動時,會嘗試從其餘節點實例上拷貝相關的shard副本至本地,這樣會浪費大量的時間和耗費高額的IO資源。若是實時分配選項關閉了,那麼當新的實例啓動,嘗試加入集羣的時候,它不會從其餘實例上拷貝shard副本。當實例徹底啓動以後,則應該再將該選項開啓,以提供長期的容災。
curl -XPUT localhost:9200/_cluster/settings -d '{ "transient" : { "cluster.routing.allocation.enable" : "none" } }'
關閉所要升級版本的節點實例,並將其移除集羣
curl -XPOST 'http://localhost:9200/_cluster/nodes/_local/_shutdown'
移除節點以後,等待剩餘節點數據轉移完成,直到肯定全部的shard都被正確地分配。
升級節點的Elasticsearch版本,最簡單和最安全的辦法就是下載一個全新的Elasticsearch版本到本地,並將原來Elasticsearch的配置文件複製到新的版本中,最好能創建一個Elasticsearch的軟鏈接到最新版本文件所在的目錄,這樣能夠方便未來使用。
啓動已經升級好的節點ES實例,並檢查其是否正確地加入到集羣中。
從新開啓shard reallocation選項(實時分配選項)
curl -XPUT localhost:9200/_cluster/settings -d '{ "transient" : { "cluster.routing.allocation.enable" : "all" } }'
檢查全部的shard是否正確地被分配,並觀察集羣是否有執行負載均衡(也是就說每一個節點被分配相等數目的shard)
重複以上過程至集羣中的每一個節點,直至這個集羣中全部節點完成版本升級。
說明:由於目前Elasticsearch的版本都逐漸成熟,曾經的遺留版本基本上不多見到了,所以從1.0版本以前升級到1.0版本以後的步驟就不一一說明了,這個過程將不得不重啓整個集羣系統才能完成整個版本升級的過程,這裏再也不詳細闡述,若有興趣可參看:https://www.elastic.co/guide/en/elasticsearch/reference/current/setup-upgrade.html
目前暫時總結這麼多了,未來會持續更新。