[譯] Elasticsearch 滾動升級

• 原文地址：Rolling upgrades
• 原文做者：elastic.
• 譯文出自：掘金翻譯計劃
• 本文永久連接：github.com/xitu/gold-m…
• 譯者：code4j
• 校對者：Xekin-FE, ClarenceC

Elasticsearch 滾動升級

滾動升級容許 Elasticsearch 集羣在業務不中斷的狀況下更新一個節點。集羣中不支持同時運行多個版本，由於分片不會重新版本分配到舊版本的節點上。

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

滾動升級步驟以下：

第一步: 滾動升級步驟以下：

當你關閉一個節點以後，分片分配進程會嘗試當即將分片從當前節點複製到集羣上的其餘節點，致使浪費了大量的 I/O 操做。要想避免這個問題能夠經過在關閉節點前禁用這個進程

PUT /_cluster/settings
{
  "transient": {
    "cluster.routing.allocation.enable": "none"
  }
}
複製代碼

第二步：中止沒必要要的索引，並執行同步刷新（這一步可選）

你能夠在升級期間愉快的進行索引操做，固然，若是你使用以下命令，中止沒必要要的索引，並執行同步刷新synced-flush請求，分片恢復速度會更快：

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"
  }
}
複製代碼

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

等待集羣分片平衡結束後，再升級下一個節點。這一過程可使用_cat/health命令檢查：

GET _cat/health
複製代碼

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

重點：滾動升級過程當中，高版本上的主分片不會把副本分配到低版本的節點，由於高版本的數據格式老版本不認。 若是高版本的主分片無法分配副本，換句話說若是集羣中只剩下了一個高版本節點，那麼節點就保持未分配的狀態，集羣健康會保持 yellow。 這種狀況下，檢查下有沒有初始化或分片分配在執行。 一旦另外一個節點升級結束後，分片將會被分配，而後集羣狀態會恢復到 green 。

沒有使用同步刷新的分片恢復時間會慢一點。分片的狀態能夠經過_cat/recovery請求監控：

GET _cat/recovery
複製代碼

若是你在這以前中止索引操做，那麼在節點恢復完成以後重啓也是安全的。

第七步：重複上述步驟

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

---

掘金翻譯計劃 是一個翻譯優質互聯網技術文章的社區，文章來源爲 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智能等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。