Elasticsearch集羣的版本升級是一項重要的集羣維護工做。本篇文章參考官方文檔,將詳細介紹相關細節。html
對於Elasticsearch的生態圈組件須要同步升級,具體配套版本能夠參考官方提供的升級指南。node
Elasticsearch對於老版本的索引(index)兼容性以下:json
若是升級過程當中遇到索引不兼容場景,升級後集羣將沒法正常啓動。api
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
。方案分別爲:多線程
按照上面的升級路線有兩種升級方案:併發
一樣有兩個方案:app
集羣升級路線中,針對不一樣的版本之間升級,一共有三種升級方案:滾動升級、集羣重啓、reindex。下面將分別介紹。
所謂滾動升級指的是集羣中節點逐個將版本升級至目標(高)版本,升級期間集羣保持對外服務不中斷。這種升級方案都是針對同一個大版本內的升級,即x.y升級到x.z(z>y)。特別的,5.6升級到6.x也是支持使用滾動升級方式的。
https://www.elastic.co/guide/en/elasticsearch/reference/current/rolling-upgrades.html
一般滾動升級的步驟以下:
在下宕升級節點前,須要提早禁止副本分片的分配。
節點下宕後,副本分配進程會等待
index.unassigned.node_left.delayed_timeout
(默認狀況下爲1分鐘),而後再開始將該節點上的分片複製到羣集中的其餘節點,這會致使大量I/O。因爲節點很快將從新啓動,因此並不須要從新分配。
API命令以下:
PUT _cluster/settings { "persistent": { "cluster.routing.allocation.enable": "primaries" } }
重啓集羣時若是translog過大,日誌回放恢復數據耗時較長,建議手動同步刷新,減小translog。
注意:這個過程較爲緩慢。
POST _flush/synced
若是集羣中運行了機器學習任務,須要中止任務運行。
參考:https://www.elastic.co/guide/en/elastic-stack-overview/6.8/stopping-ml.html
對升級節點實施下宕,開始文件系統的升級。
啓動節點,並用下面的API檢查節點是否加入集羣。
GET _cat/nodes
節點加入集羣后,設置啓用分片分配開始使用該節點。
PUT _cluster/settings { "persistent": { "cluster.routing.allocation.enable": null } }
在升級下一個節點前,等待集羣分片完成。能夠經過下面的API檢查集羣狀態:
GET _cat/health?v
等待集羣的狀態由red變成yellow,再到green。說明集羣完成全部主分片和副分片的分配。
重複滾動升級集羣其餘節點。
若是集羣中有機器學習任務,須要重新啓動。
集羣總體重啓指的是升級前將集羣全部節點均下宕,集羣中止對外服務,待全部節點完成升級後,總體啓動集羣,恢復對外服務。例如:5.6以前的版本升級到6.x須要重啓集羣實施升級。
https://www.elastic.co/guide/en/elasticsearch/reference/current/restart-upgrade.html
集羣重啓升級步驟和滾動方式類似,主要步驟以下:
下宕升級節點前須要,提早禁止副本分片的分配。(參考滾動升級)
參考滾動升級。
參考滾動升級
對集羣全部節點實施下宕,開始文件系統版本升級。
啓動全部節點,並用下面的API檢查全部節點是否加入集羣。
GET _cat/nodes
節點加入集羣后,設置啓用分片分配開始使用該節點。
PUT _cluster/settings { "persistent": { "cluster.routing.allocation.enable": null } }
在升級下一個節點前,等待集羣分片完成。能夠經過下面的API檢查集羣狀態:
GET _cat/health?v
等待集羣的狀態由yellow變爲green。說明集羣完成全部主分片和副分片的分配。
參考滾動升級
Elasticsearch中相鄰版本的index具備兼容性,可是跨度較大的版本再也不向下兼容。在上文(1.2 索引兼容性)中已作介紹。而在ElasticSearch中,索引的field設置是不能被修改的,若是要修改一個field,那麼應該從新按照新的mapping,創建一個index,而後將數據批量查詢出來,從新用bulk api寫入新index中。
批量查詢的時候,建議採用scroll api,而且採用多線程併發的方式來reindex數據,每次scroll就查詢指定日期的一段數據,交給一個線程便可。
申請服務器資源,搭建全新版本的ElasticSearch集羣。將對外服務所有指向新集羣。
在老集羣上使用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名。
遷移完成後,能夠對舊集羣中數據實施清理。清理完成後根據狀況須要,舊節點能夠離線升級文件系統,最後做爲全新的節點加入新集羣。
若是舊集羣中歷史數據不重要,能夠刪除數據後,搭建全新的集羣。
對於跨度較大的版本升級,若是不採用新建集羣再實施reindex方式,那麼就須要分步升級。例如A、B、C依次爲三個版本,版本級別A<B<C,其中index數據B兼容A,C兼容B,可是C不兼容A。這種狀況須要分步升級:
若是index數據是時間序列類的數據,能夠不實施reindex,等到歷史數據生命週期結束後(集羣中不在有A版本的index數據),再從B版本升級到C版本。
(1)通常Elasticsearch大版本之間跨度升級須要重啓總體集羣。
(2)部分ElasticSearch大版本間index並不兼容,須要對數據重索引(reindex)。
(3)大版本中的小版本升級,一般只須要滾動重啓方式便可。
一、Elasticsearch官網 連接:https://www.elastic.co/cn/
更多關注: