背景
因爲ES所在機器,有會大量佔用cpu和內存的軟件,導致ES運行不穩定甚至無法響應的問題。我們對ES的服務進行了遷移。
遷移方法
我們使用的ES版本是2.3.3,現在已經更新到了5.x版本(當時5.6.1)。而且ES更新到5.x後,增加了很多新特性和性能的優化。因此,我們也正好準備借這次遷移,將ES給升級了。
最初遷移和升級方法是基於官網資料,得出的方法如下:
- 在新環境安裝相同2.3.3 ES集羣。
- 數據遷移:使用ES鏡像導出和恢復的方法進行數據遷移
- 升級: 使用ES官網介紹升級方法進行升級。
官網升級方法主要針對原來的ES集羣進行升級,我們的需求就是在新的環境使用新版本。所以我們的想法:
- 直接在新環境搭建最新版本的ES集羣(5.6.1),
- 遷移數據。
這樣用兩步完成ES遷移和升級。
基於這個思路,找到了一些遷移工具:
elasticsearch-migration。這個工具正好srcoll+bulk原理,進行數據遷移,該工具安裝簡單,解壓即可使用。
scroll查詢:es深度分頁查詢,基於http請求,可以查詢索引下所有數據,不會有from+size不能大於1w的問題。
bulk請求:可以批量插入數據,是http請求。
elasticsearch-dump.安裝環境依賴npm。網上有人嘗試 說有不成功的,而且覺得安裝比較麻煩,就棄了。
Elasticsearch-Exporter. 這個運行環境同樣依賴npm。這個運行方式和elasticsearch-migration有些類似。但是相比較還是elasticsearch-migration安裝簡單。
經過對比分析Elasticsearch-Migration安裝和使用都比較簡單,最終選擇了Elasticsearch-Migration。
Elasticsearch-Migration介紹
- elasticsearch-migration支持:多個版本間的數據遷移,使用scroll+bulk的接口原理。
From | To |
---|---|
1.x | 1.x |
1.x | 2.x |
1.x | 5.0 |
2.x | 1.x |
2.x | 2.x |
2.x | 5.0 |
5.0 | 1.x |
5.0 | 2.x |
5.0 | 5.0 |
我們此次遷移的版本正好在支持的列表裏。同時也在測試環境進行驗證。
- 在測試環境對遷移效率進行評估:
測試數據: 46894/13s≈3600/s。每條數據有13個字段。
線上數據:數據量39,390,354,大小:約13.7G,總共時間大約半小時。 安裝和使用
elasticsearch-migration支持linux,windows等不同系統,下載解壓後可以直接運行。使用示例
./esm -s http://192.168.1.x:9200 -d http://192.168.1.y:9200 -x index_name -w=5 -b=10 -c 10000
-w 表示線程數
-b 表示一次bulk請求數據大小,單位MB默認 5M
-c 一次scroll請求數量
[更詳細參數可參考官網]
遷移步驟
方案確定好了,工具也有了,下面開始做遷移。
下載、安裝、配置新的ES集羣
(包括ElasticSearch.xml、jvm.options配置)。5.6.1Es的JVM參考包括最大/小內存(-Xms,-Xmx),GC都可以在jvm.options進行配置,不需要加在es啓動裏了。
安裝ES插件:IK(中文分詞器),X-pack(5.x之前用X-pack,之前用Marvel)
遷移ES模板。
業務和數據遷移(遷移關鍵步驟):
4.1 停止微信同步任務、關掉Logstash應用(廖XX)
4.2 同步舊ES集羣數據到新ES集羣(運維-王XX),確認數據同步沒有問題(廖XX,測試-魏XX),主要同步微信數據
4.3 發佈新代碼分支,確認業務(廖xx、測試-魏xx)
4.4 開啓確認微信同步任務(測試-魏xx),修改logstash配置重新啓動(廖xx)
這一步涉及到多個組之間的合作,所以將遷移過程不同的同事對應工作內容都列出來,這樣在實際過程中,大家能有清晰的過程,減少遷移過程的溝通成本。
批量索引遷移腳本:
遷移以srcIndex1,scrIndex2爲前綴的索引
#!/bin/sh
dir="/tmp/es/es/bin/linux64"
cd $dir
esindex=`curl -s 'http://10.10.10.10:9204/_cat/indices' | grep -e 遷移srcIndex1* -e scrIndex2* | awk '{print $3}'`
#echo $esindex
for i in $esindex;
do
./esm -s http://10.10.10.10:9204 -x $i -d http://10.10.10.11:9204 -x $i -w=5 -b=10 -c 10000
done
[腳本貢獻者:王振偉]
ES升級過程的注意點、問題
- 因爲ELK中Kibana版本依賴ES的版本的,在ES升級同時,Kibana 也需要升級。
- 有的時候可能不是最新的就是最合適的,在選擇新版本過程中需要進行評估:比如插件的支持,尤其是第三方插件。我們用了IK中文分詞插件,當時ES最新版的是5.6.2,而IK最新版的還只支持到5.6.1.
- elasticsearch-migration只會插入數據,不會更新數據。所以在第四步做業務遷移時,若是遷移數據量較大,可以考慮先將遷移可能會被修改數據,對於其他確定不會被修改的數據,可以等業務遷移完成之後,再進行。
- IK配置文件:2.3.3版本IK的配置是在ES安裝目錄plugin下面,5.6.1版本是在ES安裝目錄的config下。
- 5.x string分爲text和keyword兩種數據類型。
- 因爲5.x對一些查詢(比如filter查詢)和聚合查詢進行的調整,在業務應用遷移之前,需要在測試環境下先對原有業務進行迴歸測試。目前我發現的有:
- 5.x版本,term聚合查詢時,聚合中size不能爲0,否則會報錯。
- 5.x 對於filter查詢結構進行調整,迴歸業務測試時需要注意。
總結
數據遷移過程其實並沒有使用很高深的技術,關鍵還是在安排好遷移過程中每一個步驟:包括遷移前,新集羣的測試、業務測試,尤其業務遷移過程中,不同組之間的配合安排。
另外,在安裝新應用時候,需要確認該環境,避免和已有其他應用在CPU、內存等使用上是的衝突,以免影響軟件運行的穩定性。