elasticsearch跨集羣數據遷移

寫這篇文章，主要是目前公司要把ES從2.4.1升級到最新版本7.8，不過如今是7.9了，官方的文檔：https://www.elastic.co/guide/en/elasticsearch/reference/current/index.html

因爲從2.4.1跨很大基本的升級，因此不能平滑的升級了，只能從新搭建集羣進行數據遷移，因此遷移數據是第一步，可是呢，2.4.1是能夠支持多個type的，如今的新版已經不能支持多個type了，因此在遷移的過程當中要將每個type創建相應的索引，目前只是根據原先的type之間建立新的索引，還沒考慮到業務的需求，這個可能須要從新設計索引。

本文主要針對在實際過程當中遇到的幾個問題進行闡述，第一步遷移的方案選擇，第二怎麼去遷移，第三對遇到的問題進行解決

1、遷移方案的選擇

主要參考下這篇文章：https://www.jianshu.com/p/50ef4c9090f0

我我的以爲比較熟悉的方法選擇三種：

一個是備份和還原，也就是說使用snapshot，官方的網址：https://www.elastic.co/guide/en/elasticsearch/reference/current/snapshot-restore.html

 

而後發現只能跨一個版本升級，並不不符合我目前的需求，因此排除這個方案。

第二個是使用elk的方式，使用logstash，我有另一篇文章介紹這個的玩法：從0到1學會logstash的玩法（ELK）

logstash的官方文檔：https://www.elastic.co/guide/en/logstash/current/index.html

這個方法確實能夠實現遷移，可是對於不熟悉這個elk的童鞋來講有點難，由於剛開始接觸，也不是那麼的友好，因此我在這裏並無優先選擇。

第三種方案就是採用elasticsearch的一個接口_reindex，這個方法很簡單，官方文檔也很詳細，上手也比較快，因此選擇了該方案，之前也沒接觸過，因此也要研究下吧，因此就有官方的文檔：https://www.elastic.co/guide/en/elasticsearch/reference/7.9/docs-reindex.html，對英文不是很熟的童鞋徹底能夠搜索其餘博客，不少博客都有詳細的介紹，我也是看別人的博客，可是忘記網址了，而後再來看官網補充下，畢竟官網的是比較可信點。

 

2、遷移的語法

咱們的需求是跨集羣進行數據遷移，因此這裏不說同集羣的遷移，由於對於跨集羣來講，同一個集羣更簡單。

第一步：配置新版es的參數，就是配置白名單，容許哪一個集羣能夠reindex數據進來，在官網copy了一段，根據本身的實際狀況進行修改就好，須要重啓

reindex.remote.whitelist: "otherhost:9200, another:9200, 127.0.10.*:9200, localhost:*"

第二步：就是在新版的es上創建索引，設置好分片，副本（剛開始爲0吧）等，由於自動建立的分片和副本都是1，因此本身先建立好索引比較好

第三步：直接配置啦，這裏我就直接貼代碼了，具體的介紹能夠去看官網啦

curl -u user:password   -XPOST "http://ip_new:port/_reindex" -H 'Content-Type:application/json'  -d '  #這裏的user，port，ip，password都是新集羣的
{
  "conflicts": "proceed",
  "source": {
    "remote": { #這是2.4.1的配置
      "host": "http://ip:port/",  
      "username": "user",
      "password": "password"
    },
    "index": "index_name_source", #2.4.1的要遷移的索引
    "query": {
       "term": {
        "_type":"type_name"  #查詢單個type的數據
}
    },
    "size": 6000  #這個參數能夠根據實際狀況調整
  },
  "dest": {
    "index": "index_name_dest",  #這裏是新es的索引名字
  }
}'

好，很好，好了，那就跑起來，剛開始第一個小的索引跑起來沒任何問題，剛開始覺得就這麼簡單，後來索引大了，不合理的設計，就出現下面的問題了

3、遇到的問題和解決方案

我。。。這是神馬設計，一個文檔的id這麼長id is too long, must be no longer than 512 bytes but was: 574;

 

 由於在elasticsearch7.8中的id最長爲512啦，能夠看看這個：https://github.com/elastic/elasticsearch/pull/16036/commits/99052c3fef16d6192af0839558ce3dbf23aa148d

 

沒啥不服氣的吧，那怎麼解決這個問題呢，id好像很差改吧，網上都說要本身寫代碼去從新縮短這個id的長度。好吧，感受有點複雜了，我又去看reindex這個文檔的，官方文檔啦，原來還支持腳本呢，可是這裏這個支持的腳本有點強大，比那個update_by_query的腳本強大，能夠改id哦，

 

 看到沒，這些均可以修改，看到了但願有沒有？接下我就修改遷移的代碼啦：

curl -u user:password   -XPOST "http://ip_new:port/_reindex" -H 'Content-Type:application/json'  -d '  #這裏的user，port，ip，password都是新集羣的
{
  "conflicts": "proceed",
  "source": {
    "remote": { #這是2.4.1的配置
      "host": "http://ip:port/",  
      "username": "user",
      "password": "password"
    },
    "index": "index_name_source",
    "query": {
       "term": {
        "_type":"type_name"  #查詢單個type的數據
　　}
    },
    "size": 6000  #這個參數能夠根據實際狀況調整
  },
  "dest": {
    "index": "index_name_dest",  #這裏是新es的索引名字
  },
  "script": {
    "source": "if (ctx._id.length()>512) {ctx._id = ctx._id.substring(0,511)}",  #這裏我簡單粗暴，截斷了，各位能夠根據需求去改，這裏和java的語法類似的
    "lang": "painless"
  }
}'

果真解決了問題，遷移數據沒問題了，很好，很是好，可是老是不那麼如意，當一個索引很大，3+個T的數據（吐槽下，什麼鬼，原來的索引還只有6個分片，這個設計。。。）就會curl出問題了，出問題了，中途中斷了，說是沒法接收到網絡數據：

curl: (56) Failure when receiving data from the peer  #這個問題網上不少人都問，可是都沒解決方案，有人說這是bug

就這麼認命了嗎，每次跑了一半多，白乾活了，這個錯誤也是真的沒啥詳細說明呀，有點慘，我想升級這個curl的版本，可是升級失敗了

 

 算了，沒勁，那就換一個centos7.x的機器看看curl的版本吧，果真比這個高一些，那就換機器繼續試試啦。果真沒讓我失望，沒在出現這個問題了。好吧順利的去遷移數據去了，不過那個size參數是能夠調整的，太大了會報錯的，要根據文檔的大小*size，這個值在5-15M之間速度會比較快一些，我這也還沒對比測試。

這裏感謝各個寫博客的博主，看了不少的博客，解決問題思路，可是沒有記錄下，如今也就記得這麼多了，很久沒寫博客了，最近看了不少基礎的書，果真出來混早晚是要還的，之前落下的基礎知識，總要花費一個代價補回去的，也但願本身可以與各位童鞋一塊兒學習進步，一直相信最好的學就是教會別人