Elasticsearch官檔翻譯——2.6 升級

weixin_33670713發表於2018-03-09

文章名稱：Elasticsearch Reference[2.2]

原文地址：https://www.elastic.co/guide/en/elasticsearch/reference/2.2/setup-upgrade.html

譯者：code4j

升級

升級前請注意：

參考版本變化文件。
升級前請在在開發環境測試升級版本。
升級前備份資料。不做備份的話是沒法回滾到上一版的。

Elasticsearch通常可以使用滾動升級步驟，服務不會中斷。這章詳細介紹如何進行滾動升級和停機升級。

當前版本是否支援滾動升級，請參照如下表格：

升級前	升級後	支援的升級方式
0.90.x	2.x	停叢集升級
1.x	2.x	停叢集升級
2.x	2.y	滾動升級(y>x)

備份你的資料

升級之前請經常做備份，這樣出了問題你可以回滾。升級有時候還包括Lucene版本升級，Lucene升級後更新的索引可能在原來版本的Elasticsearch上跑不起來。

備份1.0往後的版本

在1.0往後的版本做備份，使用快照這一特性會方便很多，詳細指示看這裡：backup and restore with snapshots。

備份0.9及以前的版本

備份0.90.x版本步驟如下：

第一步：

下面這一步防止備份的時候索引重新整理到磁碟：

PUT /_all/_settings
{
  "index": {
    "translog.disable_flush": "true"
   }
}

第二步：

下面這步防止叢集備份的時候，資料從一個節點平衡到另一個節點。

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

第三步：備份你的資料

等再平衡和索引重新整理禁用後，用你喜歡的方法開始備份資料（打成tar包，使用儲存快照或者備份軟體）

第四步：重新開啟再平衡和索引重新整理

當備份完成，不需要再從Elasticsearch讀取資料後，必須要重新開啟再平衡和索引重新整理：

PUT /_all/_settings
{
  "index": {
    "translog.disable_flush": "false"
  }
}

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

滾動升級

滾動升級允許Elasticsearch叢集一個節點一個節點升級，不需要停機。叢集中不支援同時執行多個版本，因為分片不會從新版本分配到舊版本的節點上。

從這個列表中檢查當前版本的ES是否支援滾動升級。

滾動升級步驟如下：

第一步：禁用分片再平衡

當你關閉一個節點時，分片分配程式將分片從當前節點複製到叢集另一個節點上，這將會浪費大量的I/O操作。可以在關閉節點前禁用這個特性：

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

第二步：停止不必要的索引，並執行同步重新整理（這一步可選）

你可以在升級期間愉快的進行索引操作，當然，如果你使用如下命令，停止不必要的索引，並執行同步重新整理，分片恢復速度會更快：

POST /_flush/synced

同步重新整理是錦上添花的操作。如果出現索引掛起的現象操作就會失敗，為了安全起見有必要多試幾次。

第三步：單個節點停機並升級

升級前關閉一個節點。

注意：當使用zip或tar包升級，預設情況下Elasticsearch home目錄下的config，data，log，plugins等目錄都會被覆蓋。
最好解壓到不同的目錄，這樣升級期間就不會刪除原來的目錄了。自定義的目錄可以通過path.conf和path.data來設定。
RPM或DEB包會把目錄放到合適的位置。

使用rpm/deb安裝包升級：

使用rpm或dpkg安裝新包，所有的目錄都會被放到合理的位置，配置檔案不會被覆蓋。

使用zip或tar包解壓安裝：

解壓安裝包，確保不要覆蓋config和data目錄。
從舊的安裝目錄拷貝conf目錄到新安裝目錄，或者使用--path.conf選項到外部的config目錄
從舊的安裝目錄拷貝data目錄到新的安裝目錄，或修改config/elasticsearch.yml中的path.data設定data目錄為原來的目錄。

第四步：啟動升級過的節點

啟動升級後的節點並確認加入到叢集中，可以通過日誌或下面的命令來確認：

GET _cat/nodes

第四步：重新開啟分片再平衡

當節點加入叢集后，使用以下命令重啟分片再平衡：

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

第六步：等待節點恢復正常

等待叢集分片平衡結束後，再升級下一個節點。這一過程可以使用下面的命令檢查：

GET _cat/health

等到status這一列由yellow變成green，Green表示主分片和副本都分配完了。

重點：滾動升級過程中，高版本上的主分片不會把副本分配到低版本的節點，因為高版本的資料格式老版本不認。
如果高版本的主分片沒法分配副本，換句話說如果叢集中只剩下了一個高版本節點，那麼節點就保持未分配的狀態，叢集健康會保持yellow。
這種情況下，檢查下有沒有初始化或分片分配在執行。
一旦另一個節點升級結束後，分片將會被分配，然後叢集狀態會恢復到green。

沒有使用同步重新整理的分片恢復時間會慢一點。分片的狀態可以通過_cat/recovery
請求監控：

GET _cat/recovery

第七部：重複上述步驟

當叢集穩定並且節點恢復後，對剩下的節點重複上述過程。

停叢集升級

當升級跨越大版本的Elasticsearch時，需要停叢集重啟：從0.x到1.x或1.x到2.x等。滾動升級不支援跨大版本的叢集。
按照以下步驟進行停機群升級：

第一步：禁用分片分配

當你關閉一個節點時，分片分配程式將分片從當前節點複製到叢集另一個節點上，這將會浪費大量的I/O操作。可以在關閉節點前禁用這個特性：

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

如果從0.90.x升級到1.x，使用以下配置：

PUT /_cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.disable_allocation": true,
    "cluster.routing.allocation.enable": "none"
  }
}

第二步：執行同步重新整理

停止不必要的索引，並執行同步重新整理，分片恢復速度會更快：

POST /_flush/synced

同步重新整理是錦上添花的操作。如果出現索引掛起的現象操作就會失敗，為了安全起見有必要多試幾次。

第三步：關閉並升級全部的節點：

關閉叢集全部節點的ES服務，每個節點使用和滾動重啟一樣的方法升級每個節點。

第四步：啟動叢集

如果你有專門的master節點群（master節點就是node.master為true並且node.data為false的節點），最好先啟動它們。等待它們形成叢集並選舉出主節點。這個過程可以通過日誌檢查。

一旦達到最小可選舉主節點個數時，將會形成一個叢集並選舉出主節點。然後就可以通過_cat/health 和 _cat/nodes API監控節點加入雞群的情況：

GET _cat/health
GET _cat/nodes

使用上述API檢查節點是否成功加入叢集。

第五步：等待叢集恢復至`yellow`

只要節點加入叢集，節點上的主分片就開始在本地恢復。最初_cat/health將會返回red狀態，表示有主分片還沒分配。
一旦每個節點的本地分片都恢復了，狀態將會變成yellow，表示所有的主分片都分配了，但並不是所有副本都有分配。這就是期待的效果，畢竟分片平衡還被禁用中。

第六步：重啟平衡

延後副本分配，直到所有節點都加入叢集，master就可以給本地已有分片拷貝的節點分配副本了。這時所有節點都在叢集中，可以安全得重啟分片平衡了。

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