Elasticsearch 2.3.0 老版本升級指南

    Elasticsearch一般可使用滾動升級過程，致使服務不中斷。本文詳細介紹如何執行滾動升級與集羣的升級重啓。Elasticsearch不是全部版本均可以直接升級。升級前請先查閱相關文檔，而後進行數據備份，最好在測試環境下模擬作一遍。升級能夠參照如下內容。

從0.90.x到2.x須要全集羣重啓。

從1.x到2.x須要全集羣重啓。

從2.x到2.y能夠不用所有重啓，使用滾動升級完成（y>x）。

插件問題，在升級的時候，同時要考慮到插件問題，最好插件的版本和Elasticsearch版本一致。

在每一個節點上升級和重啓的過程爲：
一、關閉Elasticsearch
二、升級Elasticsearch
三、升級插件
四、啓動Elasticsearch

集羣重啓步驟：

一、關閉分片分配。

當咱們視圖關閉一個節點的時候，Elasticsearch會當即試圖複製這個節點的數據到集羣中的其餘節點上。這將致使大量的IO請求。在關閉該節點的時候能夠經過設置一下參數來避免此問題的發生。

PUT /_cluster/settings
{
  "transient": {
    "cluster.routing.allocation.enable": "none"
  }
}

二、執行一個同步刷新

當中止一個索引的時候，分片的恢復會很快，因此要進行同步刷新請求。

POST /_flush/synced

同步刷新請求是很是有效的一種操做，當任何索引操做失敗的時候，能夠執行同步刷新請求，必要的時候能夠執行屢次。

三、關閉和升級全部節點
中止在羣集中的全部節點上的服務。每個節點都要進行單獨升級。這個主要就是文件替換操做，注意保留日誌目錄。

四、啓動集羣

若是你有專門的主節點（node.master 節點設置爲true和node.data設置爲false），則先啓動主節點。等待它們造成一個集羣，而後選擇一個主數據節點進行啓動。你能夠經過查看日誌來檢查啓動狀況。經過下面命令能夠監控集羣的啓動狀況，檢查全部節點是否已成功加入羣集。

GET _cat/health

GET _cat/nodes

五、等待黃色集羣狀態

當節點加入集羣后，它首先恢復存儲在本地的主分片數據。最初的時候，經過 _cat/health請求發現集羣的狀態是紅色，意味着不是全部的主分片都已分配。當每一個節點都恢復完成後，集羣的狀態將會變成黃色，這意味着全部主分片已經被找到，可是並非全部的複本分片都恢復。

六、從新分配

延遲的副本的分配直到全部節點都加入集羣，在羣集的全部節點，能夠從新啓用碎片分配：

PUT /_cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.enable": "all"
  }
}

這個時候集羣將開始複製全部副本到數據節點上，這樣能夠安全的恢復索引和搜索，若是你能延遲索引和搜索直到全部的碎片已經恢復，這樣能夠加快集羣的恢復。能夠經過下面API監控恢復的進度和健康狀況：

GET _cat/health

GET _cat/recovery

最後當集羣的狀態出現爲綠色的時候，表示本次集羣升級所有完成。

賽克藍德 secisland  

滾動升級

滾動升級容許Elasticsearch集羣升級一個節點，同時又不影響系統的使用。在同一個集羣中的全部節點的版本最好保持一致，不然可能會產生不可預知的後果。滾動升級的步驟以下：

一、關閉分片分配。

當咱們視圖關閉一個節點的時候，Elasticsearch會當即試圖複製這個節點的數據到集羣中的其餘節點上。這將致使大量的IO請求。在關閉該節點的時候能夠經過設置一下參數來避免此問題的發生。

PUT /_cluster/settings
{
  "transient": {
    "cluster.routing.allocation.enable": "none"
  }
}

二、中止沒必要要的索引和執行同步刷新（可選）

您能夠在升級過程當中繼續索引。然而，若是你暫時中止沒必要要的索引碎片，但它恢復要快得多。因此能夠執行同步刷新操做。

POST /_flush/synced

同步刷新請求是很是有效的一種操做，當任何索引操做失敗的時候，能夠執行同步刷新請求，必要的時候能夠執行屢次。

三、中止和升級一個節點

在啓動升級前，將節點中的一個節點關閉。能夠經過綠色解壓安裝或者經過rpm等安裝包安裝。

不論是解壓安裝仍是壓縮包安裝都要保留以前的數據文件不能被破壞。能夠在新的目錄中安裝，把path.conf和path.data的位置指向以前的數據。

四、啓動升級節點

啓動「升級」節點，並經過接口檢查是否正確：

GET _cat/nodes

五、啓用共享配置
一旦節點加入羣集，在節點從新啓用碎片分配：

PUT /_cluster/settings
{
  "transient": {
    "cluster.routing.allocation.enable": "all"
  }
}

六、等待節點恢復
你應該等待集羣升級的下一個節點以前完成碎片分配。能夠經過如下接口進行檢查：

GET _cat/health

等待的狀態欄從黃到綠色。現態綠色意味着全部主分片和副本分片已經完成分配。

重要：在滾動升級期間，主碎片被分配到一個更高版本節點不會有副本分配到一個較低的版本節點，，由於新版本的數據結構可能舊版本不能識別。

一旦另外一個節點升級，副本將被分配，羣集的健康狀態將達到綠色。

沒有同步刷新碎片可能須要一些時間來恢復。恢復的狀態和每一個節點的監控能夠用如下接口。

GET _cat/recovery

若是你中止了索引，那麼恢復索引的恢復是安全的。

七、重複其餘節點

當集羣是穩定的，節點已經恢復，重複上述步驟，把全部剩餘的節點進行升級。

賽克藍德(secisland)後續會逐步對Elasticsearch的最新版本的各項功能進行分析，近請期待。也歡迎加入secisland公衆號進行關注。