Elasticsearch叢集升級指引

翔子書記發表於2021-04-08
Elasticsearch

目錄

  • 背景
  • 第一部分 版本升級指引
  • 第二部分 升級方法和具體步驟
  • 總結
  • 參考文獻及資料

背景

Elasticsearch叢集的版本升級是一項重要的叢集維護工作。本篇文章參考官方文件，將詳細介紹相關細節。

第一部分 版本升級指引

1.1 同步升級Elastic Stack元件

對於Elasticsearch的生態圈元件需要同步升級，具體配套版本可以參考官方提供的升級指南。

https://www.elastic.co/cn/products/upgrade_guide

1.2 索引相容性

Elasticsearch對於老版本的索引（index）相容性如下：

  • Elasticsearch 6.x相容Elasticsearch 5.x中建立的索引，但不相容Elasticsearch 2.x或更舊版本的索引。
  • Elasticsearch 5.x相容Elasticsearch 2.x中建立的索引，但不不相容Elasticsearch1.x或更舊版本的索引。

如果升級過程中遇到索引不相容場景，升級後叢集將無法正常啟動。

1.3 版本升級路線

Elasticsearch版本升級具體路線總結如下：

序號 原版本 升級目標版本 支援的升級型別
1 5.x 5.y 滾動升級（其中 y > x）
2 5.6 6.x 滾動升級
3 5.0-5.5 6.x 叢集重啟
4 <5.x 6.x reindex升級
5 6.x 6.y 滾動升級（其中 y > x）
6 1.x 5.x reindex升級
7 2.x 2.y 滾動升級（其中 y > x）
8 2.x 5.x 叢集重啟
9 5.0.0 pre GA 5.x 叢集重啟
10 5.x 5.y 滾動升級（其中 y > x）

關於Elasticsearch的版本序列需要特別說明一下。Elasticsearch版本序列不是連續遞增的，從2.4.x版本後直接跳躍到5.0.x。所以對於5.x版本，如果按照嚴格順序遞增編號，應該是3.x。之所以沒有連續編號，主要是為了保持ELK（Elasticsearch 、 Logstash 、 Kibana）整體版本的統一。

其中第4種情況，小於5.x其實就是2.x和1.x。由於6.x對於更低版本的索引不相容，所以需要對原叢集的中索引實施reindex。方案分別為：

1.3.1 2.x升級到6.x

按照上面的升級路線有兩種升級方案：

  • 方案1：先由2.x升級到5.6版本（reindex升級索引版本），然後由5.6升級到6.x（滾動升級）；
  • 方案2：建立全新的6.x叢集，然後將舊叢集中的索引資料遠端reindex到新叢集中；

1.3.2 1.x升級到6.x

同樣有兩個方案：

  • 方案1：先由1.x升級到2.4.x版本（reindex升級索引版本），最後按照上面2.x升級到6.x的方案實施；
  • 方案2：建立全新的6.x叢集，然後將舊叢集中的索引reindex到新叢集中；

第二部分 升級方法和具體步驟

叢集升級路線中，針對不同的版本之間升級，一共有三種升級方案：滾動升級、叢集重啟、reindex。下面將分別介紹。

2.1 滾動升級

所謂滾動升級指的是叢集中節點逐個將版本升級至目標（高）版本，升級期間叢集保持對外服務不中斷。這種升級方案都是針對同一個大版本內的升級，即x.y升級到x.z（z>y）。特別的，5.6升級到6.x也是支援使用滾動升級方式的。

https://www.elastic.co/guide/en/elasticsearch/reference/current/rolling-upgrades.html

通常滾動升級的步驟如下：

第1步 禁用副本分片（shards）分配

在下宕升級節點前，需要提前禁止副本分片的分配。

節點下宕後，副本分配程式會等待index.unassigned.node_left.delayed_timeout（預設情況下為1分鐘），然後再開始將該節點上的分片複製到群集中的其他節點，這會導致大量I/O。由於節點很快將重新啟動，所以並不需要重新分配。

API命令如下：

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

第2步 執行同步重新整理

重啟叢集時如果translog過大，日誌回放恢復資料耗時較長，建議手動同步重新整理，減少translog。

注意：這個過程較為緩慢。

POST _flush/synced

第3步 停止機器學習作業

如果叢集中執行了機器學習任務，需要停止任務執行。

參考：https://www.elastic.co/guide/en/elastic-stack-overview/6.8/stopping-ml.html

第4部 下宕待升級節點並安裝主版本和外掛

對升級節點實施下宕，開始檔案系統的升級。

第5步 啟動節點

啟動節點，並用下面的API檢查節點是否加入叢集。

GET _cat/nodes

第6步 重啟分片分配

節點加入叢集后，設定啟用分片分配開始使用該節點。

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

在升級下一個節點前，等待叢集分片完成。可以通過下面的API檢查叢集狀態：

GET _cat/health?v

等待叢集的狀態由red變成yellow，再到green。說明叢集完成所有主分片和副分片的分配。

第7步 重複升級其他節點

重複滾動升級叢集其他節點。

第8步 重啟機器學習任務

如果叢集中有機器學習任務，需要從新啟動。

2.2 叢集整體重啟

叢集整體重啟指的是升級前將叢集所有節點均下宕，叢集停止對外服務，待所有節點完成升級後，整體啟動叢集，恢復對外服務。例如：5.6之前的版本升級到6.x需要重啟叢集實施升級。

https://www.elastic.co/guide/en/elasticsearch/reference/current/restart-upgrade.html

叢集重啟升級步驟和滾動方式相似，主要步驟如下：

第1步 禁用副本分片（shards）分配

下宕升級節點前需要，提前禁止副本分片的分配。（參考滾動升級）

第2步 停止不必要的索引並執行同步重新整理

參考滾動升級。

第3步 停止機器學習作業

參考滾動升級

第4部 下宕所有節點並安裝主版本和外掛

對叢集所有節點實施下宕，開始檔案系統版本升級。

第5步 啟動節點並等待叢集狀態為yellow

啟動所有節點，並用下面的API檢查所有節點是否加入叢集。

GET _cat/nodes

第6步 重啟分片分配

節點加入叢集后，設定啟用分片分配開始使用該節點。

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

在升級下一個節點前，等待叢集分片完成。可以通過下面的API檢查叢集狀態：

GET _cat/health?v

等待叢集的狀態由yellow變為green。說明叢集完成所有主分片和副分片的分配。

第7步 重啟機器學習任務

參考滾動升級

2.3 reindex

Elasticsearch中相鄰版本的index具有相容性，但是跨度較大的版本不再向下相容。在上文（1.2 索引相容性）中已做介紹。而在ElasticSearch中，索引的field設定是不能被修改的，如果要修改一個field，那麼應該重新按照新的mapping，建立一個index，然後將資料批量查詢出來，重新用bulk api寫入新index中。

批量查詢的時候，建議採用scroll api，並且採用多執行緒併發的方式來reindex資料，每次scroll就查詢指定日期的一段資料，交給一個執行緒即可。

第1步 搭建新版本叢集

申請伺服器資源，搭建全新版本的ElasticSearch叢集。將對外服務全部指向新叢集。

第2步 將老叢集中資料reindex到新叢集

在老叢集上使用reindex API將老叢集中index歷史資料逐步遷移至新叢集。

如果叢集資料量較大，遷移過程是一個很緩慢的過程。

API案例（下面是簡單的配置）：

POST _reindex
{
  "source": {
    "remote": {
      "host": "http://otherhost:9200",
      "username": "user",
      "password": "pass"
    },
    "index": "source",
    "query": {
      "match": {
        "test": "data"
      }
    }
  },
  "dest": {
    "index": "dest"
  }
}
//host為遠端叢集（新叢集）的地址。
//username和password針對安全叢集的金鑰驗證。
//"index": "source"為舊叢集中index名，dest的所對應的是新叢集目標index名。

遷移完成後，可以對舊叢集中資料實施清理。清理完成後根據情況需要，舊節點可以離線升級檔案系統，最後作為全新的節點加入新叢集。

如果舊叢集中歷史資料不重要，可以刪除資料後，搭建全新的叢集。

2.4 分步升級

對於跨度較大的版本升級，如果不採用新建叢集再實施reindex方式，那麼就需要分步升級。例如A、B、C依次為三個版本，版本級別A<B<C，其中index資料B相容A，C相容B，但是C不相容A。這種情況需要分步升級：

  • A升級到B，使用滾動升級或者叢集整體重啟方式。
  • 對於B版本的叢集，將A版本的所有資料reindex到B版本。這個過程較為耗時。
  • 等到叢集中所有歷史index（新建的index自然是B版本）均為B版本後，升級叢集版本到C版本。

如果index資料是時間序列類的資料，可以不實施reindex，等到歷史資料生命週期結束後（叢集中不在有A版本的index資料），再從B版本升級到C版本。

總結

（1）一般Elasticsearch大版本之間跨度升級需要重啟整體叢集。

（2）部分ElasticSearch大版本間index並不相容，需要對資料重索引（reindex）。

（3）大版本中的小版本升級，通常只需要滾動重啟方式即可。

參考材料

1、Elasticsearch官網 連結：https://www.elastic.co/cn/

更多關注：

相關文章