Elasticsearch集群升級指引

目錄

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

背景

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

第一部分 版本升級指引

1.1 同步升級Elastic Stack組件

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

//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也是支援使用滾動升級方式的。

//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步 停止機器學習作業

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

參考：//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需要重啟集群實施升級。

//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": "//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官網 鏈接：//www.elastic.co/cn/

更多關註：

Tags:

VirMach 便宜 VPS

QNews

QNews