ElasticSearch集羣遷移和升級總結

背景

由於ES所在機器，有會大量佔用cpu和內存的軟件，致使ES運行不穩定甚至沒法響應的問題。咱們對ES的服務進行了遷移。

遷移方法

咱們使用的ES版本是2.3.3，如今已經更新到了5.x版本(當時5.6.1)。並且ES更新到5.x後，增長了不少新特性和性能的優化。所以，咱們也正好準備藉此次遷移，將ES給升級了。

最初遷移和升級方法是基於官網資料，得出的方法以下：

1. 在新環境安裝相同2.3.3 ES集羣。
2. 數據遷移：使用ES鏡像導出和恢復的方法進行數據遷移
3. 升級: 使用ES官網介紹升級方法進行升級。

官網升級方法主要針對原來的ES集羣進行升級，咱們的需求就是在新的環境使用新版本。因此咱們的想法：

1. 直接在新環境搭建最新版本的ES集羣(5.6.1)，
2. 遷移數據。

這樣用兩步完成ES遷移和升級。

基於這個思路，找到了一些遷移工具：

1. elasticsearch-migration。這個工具正好srcoll+bulk原理，進行數據遷移，該工具安裝簡單，解壓便可使用。

   scroll查詢:es深度分頁查詢，基於http請求，能夠查詢索引下全部數據，不會有from+size不能大於1w的問題。

   bulk請求:能夠批量插入數據，是http請求。

2. elasticsearch-dump.安裝環境依賴npm。網上有人嘗試 說有不成功的，並且以爲安裝比較麻煩，就棄了。

3. Elasticsearch-Exporter. 這個運行環境一樣依賴npm。這個運行方式和elasticsearch-migration有些相似。可是相比較仍是elasticsearch-migration安裝簡單。

通過對比分析Elasticsearch-Migration安裝和使用都比較簡單，最終選擇了Elasticsearch-Migration。

Elasticsearch-Migration介紹

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

咱們這次遷移的版本正好在支持的列表裏。同時也在測試環境進行驗證。

1. 在測試環境對遷移效率進行評估：
   測試數據： 46894/13s≈3600/s。每條數據有13個字段。
   線上數據：數據量39,390,354，大小：約13.7G，總共時間大約半小時。

2. 安裝和使用

   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請求數量

   [更詳細參數可參考官網]

3. 遷移過程還有進度條提示.
   

遷移步驟

方案肯定好了，工具也有了，下面開始作遷移。

1. 下載、安裝、配置新的ES集羣

   （包括ElasticSearch.xml、jvm.options配置）。5.6.1Es的JVM參考包括最大/小內存(-Xms,-Xmx)，GC均可以在jvm.options進行配置，不須要加在es啓動裏了。

2. 安裝ES插件：IK（中文分詞器），X-pack(5.x以前用X-pack,以前用Marvel)

3. 遷移ES模板。

4. 業務和數據遷移（遷移關鍵步驟）:

   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升級過程的注意點、問題

1. 由於ELK中Kibana版本依賴ES的版本的，在ES升級同時，Kibana 也須要升級。
2. 有的時候可能不是最新的就是最合適的，在選擇新版本過程當中須要進行評估：好比插件的支持，尤爲是第三方插件。咱們用了IK中文分詞插件，當時ES最新版的是5.6.2，而IK最新版的還只支持到5.6.1.
3. elasticsearch-migration只會插入數據，不會更新數據。因此在第四步作業務遷移時，如果遷移數據量較大，能夠考慮先將遷移可能會被修改數據，對於其餘肯定不會被修改的數據，能夠等業務遷移完成以後，再進行。
4. IK配置文件：2.3.3版本IK的配置是在ES安裝目錄plugin下面，5.6.1版本是在ES安裝目錄的config下。
5. 5.x string分爲text和keyword兩種數據類型。
6. 由於5.x對一些查詢（好比filter查詢）和聚合查詢進行的調整，在業務應用遷移以前，須要在測試環境下先對原有業務進行迴歸測試。目前我發現的有：
   • 5.x版本,term聚合查詢時，聚合中size不能爲0，不然會報錯。
   • 5.x 對於filter查詢結構進行調整，迴歸業務測試時須要注意。

總結

數據遷移過程其實並無使用很高深的技術，關鍵仍是在安排好遷移過程當中每個步驟：包括遷移前，新集羣的測試、業務測試，尤爲業務遷移過程當中，不一樣組之間的配合安排。

另外，在安裝新應用時候，須要確認該環境，避免和已有其餘應用在CPU、內存等使用上是的衝突，以避免影響軟件運行的穩定性。

 

轉自【http://tech.lede.com/2017/10/25/rd/server/ElasticSearch_migration_upgrade/】