Elasticsearch1.7到2.3升級實踐總結

概括

簡述

升級分為Elasticsearch server升級和Elasticsearch client api升級

為什么要遷移

當前團隊內多個業務方公用一套ES集群，容易被影響，重要業務應該獨自搭建一套集群

遷移的優勢：

1. 降低業務耦合性，加強不同業務隔離；
2. 豐富的資源提供更好的服務支撐；

為什么選擇ES2.3

在1.X系列之上，ES2.X算是開啟了又一個重要的里程碑，文檔的展示樣式也體現了該版本的重要性，當然了這只是冰山一角；

下邊是增強說明（下邊兩幅圖說明了同一個觀點：更優秀的功能集成在了2.X版本上）：

附上地址：https://www.elastic.co/blog/release-we-have   新功能

我們既然決定了遷移，那就一起升級到優秀的版本，2.3.3是當時最新的版本,算是比較穩定的版本，看他最近一次提交是5.17；

遷移的效果如何

    

上邊兩個接口的遷移效果

因為上周中間才開始，還在觀察期，中間的幾個突兀是期間來回切換重啟，緩存失效引起，當然，這個效果是ES Server在基本上沒怎么調優的情況下的效果，之后會一遍觀察，一遍調優，找出適合我們自己的配置；

ES升級方案

升級策略

1. 搭建自己業務獨立的ES集群(2.3.3)
2. API更新換代

配置文件

*以下列表中的參數可支持自動化配置，其余未列出來皆用默認配置（如有不妥，請及時糾偏，尤其是 配置節點類型一列）

配置參數	功能簡介	配置節點類型	自動化配置	建議配置	所屬模塊
cluster.name	集群名稱	data master	√	√	cluster
node.name	節點名稱	data master	√	√	node
node.master	是否是master	data master	√	√
node.data	是否是data	data master	√	√
index.number_of_shards	索引分片數	data master	√	√	index
index.number_of_replicas	索引備份數	data master	√	√
index.refresh_interval	refresh時間	data master	√	√
index.merge.scheduler.max_thread_count	merge線程數	data master	√	Χ
index.unassigned.node_left.delayed_timeout	一個node脫離集群后多長時間之外才開始進行一系列的備份操作	data master	√	√
index.search.slowlog.threshold.query.warn	query慢日志時間設置	data	√	√
index.search.slowlog.threshold.fetch.warn	fetch慢日志時間設置	data	√	√
index.indexing.slowlog.threshold.index.warn	index慢日志時間設置	data	√	√
monitor.jvm.gc.old.warn	gc時間設置	data master	√	√	monitor
monitor.jvm.gc.old.info		data master	√	√
monitor.jvm.gc.young.warn		data master	√	√
monitor.jvm.gc.young.info		data master	√	√
script.inline	是否支持script表達式搜索	data	√	Χ	script
script.indexed		data	√	Χ
path.logs	log日志路徑	data master	√	Χ	path
path.data	存儲數據路徑	data master	√	Χ
network.host	對外發布本機ip	data master	Χ	Χ	network
transport.tcp.port	通信端口	data master	√	Χ
http.port	http端口	data master	√	Χ
discovery.zen.ping.multicast.enabled	是否開啟相同集群名稱則組成集群	data master	Χ	Χ	discovery
discovery.zen.ping.unicast.hosts	單播機器列表	data master	√	Χ
discovery.zen.minimum_master_nodes	組成master集群的最小節點數	master	√	Χ
gateway.recover_after_data_nodes	full restart 參數設置	data	√	Χ	gateway
gateway.expected_data_nodes		data	√	Χ
gateway.expected_master_nodes		master	√	Χ
gateway.recover_after_master_nodes		master	√	Χ
gateway.expected_nodes		data master	√	Χ
gateway.recover_after_nodes		data master	√	Χ
gateway.recover_after_time		data master	√	Χ
action.disable_delete_all_indices	是否允許全部刪除	data master	Χ	Χ	action
action.destructive_requires_name	是否允許正則表達式刪除	data master	Χ	Χ
shield.enabled	是否支持shield	data master	Χ	Χ	shield

插件

• head

監控

監控方案：ElasticSearch集群監控報警指標梳理

監控效果：這部分為內部監控

異同

https://www.elastic.co/guide/en/elasticsearch/reference/current/breaking-changes-2.3.html

2.0比1.7的變化

其中紅色部分是這次遷移過程中遇到需要解決的問題，帶箭頭的是ES Server變化的相關部分，不帶箭頭的是代碼層面需要變化的部分；

其中，代碼改動部分最大的是Query DSL changes;

2.1的變化

search changes：search type的count和scan過期了；

2.2的變化

2.3的變化

比較少，摘一個

如何同步遷移時的新需求

從master分支上上新開一個branch ，每次master增加新功能，上線之后，立馬同步到新的branch，時時保證同步性；

遷移流程

1. 搭建一套新的ES2.3.3集群；
2. 全量寫入數據索引，觀察ES寫入是否正常，修改出現的問題，直至索引寫入OK；
3. 上線每天全量刷數據到索引的服務，觀察兩天，索引創建過程及結果正常；
4. 此時線上有一套1.7的刷索引服務和讀索引服務，還有一套ES2.3刷索引服務，此時ES2.3增量索引也正常進行；
5. 將搭建好的ES2.3備份集群上線，收集數據服務接入該備份集群，通過雙寫的方式保證數據正常；
6. 在3、4、5進行期間，在測試環境上部署ES2.3的搜索服務，通過這段時間線下的點擊來發現問題，修復直至搜索和1.7結果一致；
7. 原有服務4台Server，增加一台Server，發ES2.3API端的分支（該分支請求ES2.3索引），通過流量配置平台將該台server流量調至1/50，通過觀察錯誤日志和監控圖表，直至無問題；（此時有問題，通過OCTO的禁用，可以瞬間恢復）
8. 繼續放開流量，一邊放流量一遍觀察日志和監控，直到1/5，沒問題，然后發新加的3台機器，直至放入1/2流量，繼續觀察，無問題后，通過服務管理平台禁用原來ES1.7的API端而不是直接下掉服務（這樣即使有問題，可以通過服務管理平台的禁用瞬間恢復）；PS：這個觀察的時間還是蠻長的，幾個小時吧
9. 觀察一段時間沒什么問題，隨后增加少量代碼，實現一鍵切換的功能，驗證、上線，完全上線之后，一鍵切換到備份集群，沒什么問題，再切回來；
10. 觀察整個周末線上服務的一個運行情況，基本無大礙（有一個GC的問題，已經整理到需要解決的問題里邊），然后將數據收集服務里邊的一些定時任務遷移到ES2.3的收集服務里邊，上線；
11. 截止到上周末為止，升級、遷移基本完成，原有集群任務還在跑，考慮再跑這周，下周跑幾天，沒有問題的話，做一下善后處理，下掉對ES1.7的完全引用，收拾收拾代碼，開始ES2.3的業務之旅；

ES集群宕機方案

索引

采用雙寫的機制，保證當前使用索引和備份索引保持一致；

搜索

采用ZK配置，一鍵切換使用集群；