Elasticsearch集羣升級指引

目錄

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

背景

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

第一部分 版本升級指引

1.1 同步升級Elastic Stack組件

對於Elasticsearch的生態圈組件須要同步升級,具體配套版本能夠參考官方提供的升級指南。node

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

1.2 索引兼容性

Elasticsearch對於老版本的索引(index)兼容性以下:json

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

若是升級過程當中遇到索引不兼容場景,升級後集羣將沒法正常啓動。api

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.x1.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

一樣有兩個方案:app

  • 方案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)大版本中的小版本升級,一般只須要滾動重啓方式便可。

參考材料

一、Elasticsearch官網 連接:https://www.elastic.co/cn/

更多關注:

相關文章
相關標籤/搜索