背景
因為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、內存等使用上是的沖突，以免影響軟件運行的穩定性。
轉自【http://tech.lede.com/2017/10/25/rd/server/ElasticSearch_migration_upgrade/】