升級 Elasticsearch 集羣數量實戰記錄

搜索引擎 升級 Elasticsearch 集羣數量實戰記錄

 

如今線上有一個elasticsearch集羣搜索服務有三臺elasticsearch實例（es一、es二、es3），打算將其升級爲5臺（增長es四、es5）。這篇文章主要是對整個操做的過程記錄，以及出現的問題總結，包括移動數據量所須要的時間。由於，一開始因爲不知道線上數據量所有分配完須要多少時間，若是從凌晨開始操做，到早上8點都尚未同步完，這樣會影響到白天線上業務的正常使用。

準備階段

線上es集羣使用的是阿里雲服務器，copy其中一個鏡像。而後更改其elasticsearch.yml配置文件，檢查IK插件是否安裝成功。按照這個流程，準備兩臺新的服務器放入阿里雲的隔離組，並安裝好elasticsearch，測試elasticsearch實例能夠正確啓動。也作了將這兩臺服務器構建一個集羣的測試。開始升級操做前30分鐘，再次檢查elasticsearch.yml 配置。主要的修改是：

discovery.zen.minimum_master_nodes:3
discovery.zen.ping.unicast.hosts: ["es1_ip", "es2_ip","es3_ip","es4_ip","es5_ip"]

升級操做

關閉es集羣shard分配功能。對es1執行：

curl -XPUT es1_ip:9200/_cluster/settings -d '{
  "transient": {
   "cluster.routing.allocation.enable": "none"
   }
}'

而後檢查：

curl es1_ip:9200/_cluster/settings
curl es2_ip:9200/_cluster/settings
curl es3_ip:9200/_cluster/settings

獲得的結果是：

{"transient":{"cluster":{"routing":{"allocation":{"enable":"none"}}}}}

說明es集羣已經關閉shard分配功能

關閉es一、es二、es3上的monit

sudo service monit stop

手動控制elasticsearch進程的啓動，避免monit自動拉起elasticsearch進程致使意外問題

這時，新的兩臺服務器es四、es5還在隔離組。把隔離取消，而後啓動這兩臺服務器的elasticsearch實例

使用目錄下面寫好的啓動腳本，這個腳本能夠在啓動時，爲elasticsearch獲取所設定的內存(控制分配給es進程的最大內存、最小內存)，JVM的設置等

./elasticsearch.sh start

執行

curl es1_ip:9200/_cat/nodes
curl es1_ip:9200/_cat/shards
curl es1_ip:9200/_cat/health
curl es1_ip:9200/_cat/indices

驗證nodes節點信息是否變爲五個，以及shard如今的分佈狀況，應該只分布在es一、es二、es3上。es4和es5尚未shard

而後記錄下當前的indices信息

例子：

health status index    pri rep docs.count docs.deleted store.size pri.store.size
green  open   users     5   1   15036978      4262221     13.2gb          6.6gb
green  open   posts     5   1   15036978      4262221     13.2gb          6.6gb

咱們能夠看到索引的健康度、狀態、文檔數量、數據大小和主分片數量、副分片的倍數設置。記錄下這些信息，在最後升級完的時候 進行比對，看是否有誤差。若是一切正常，這些信息是不會變的。

啓動es集羣shard分配功能

這是集羣操做，因此只要對其中一臺es實例操做便可

curl -XPUT es1_ip:9200/_cluster/settings -d '{
  "transient": {
   "cluster.routing.allocation.enable": "all"
   }
}'

shard分配開始

執行：

curl es1_ip:9200/_cat/shards

curl es1_ip:9200/_cat/health

curl es1_ip:9200/_cat/indices

curl es1_ip:9200/_cat/recovery

• 觀察shards分佈狀況，是否向es4和es5分配shards。以及分配的百分比進度
• 監控es4 和 es5 服務器的elasticsearch的log
• 登入 es4和es5， 查看掛載的SSD數據盤數據量是否在增加
• 測試進行es搜索的測試，快速搜索，工單篩選，客戶篩選，觀察對線上業務的影響

這段時間，主要使用：

curl es1_ip:9200/_cat/shards

curl es1_ip:9200/_cat/health

curl es1_ip:9200/_cat/recovery

觀測shard分配進度和狀況，以及線上系統健康度。

curl es1_ip:9200/_cat/shards 能夠看見具體哪一個索引的，哪一個es服務器在移動shard到另外一臺es服務器

正在shard移動時的狀態
posts r RELOCATING  3628884   5.4gb es_ip1   elasticsearch1 -> es_ip5 elasticsearch5

能夠看到哪一個索引，哪一個shard分片，從哪臺服務器上移到另外一臺服務器上

這個過程發現，elasticsearch會選擇將reproduction shard(副本分片)移到新的elasticsearch服務器上，而避免移到主分片。

這樣能夠避免移到主分片時候發生數據丟失的狀況，而移動副本分配不用擔憂這個問題，而且線上的health一直是green。儘量不影響線上正常搜索業務。

移動shard默認是兩個併發操做。一開始誤解了，覺得每一個es實例會進行兩個併發的shard移動，會有6個shard在併發移動，實際狀況是，整個集羣只有2個shard在併發移動。下次能夠將這個值調大一些，加快shard的移動速度，幸虧shard數據移動的速度比想象的要快。

經過htop觀察服務器的負載，在進行shard分配的服務器，CPU使用率通常在20%-40%之間。服務器是16核，也就是一個elasticsearch進程shard的移動，一個核心都沒有跑滿，服務器負載在0.2。可見elasticsearch的分片移動仍是很保守的，對服務器幾乎沒有很大的壓力。而且觀察發現，elasticsearch不會一次把某個索引該分配的shard都分配完再選擇下一個索引，而是輪詢的分配索引的shard。A 索引分配了一個shard，就分配B索引的shard，一圈以後，又回到A 索引繼續分配shard。直到最後全部索引shard數量在集羣中平衡。

收尾操做

大約一個小時時間，shard分配結束。一共將88G左右的數據分配到了兩臺新的服務器上。這是在默認shard併發分配數2的狀況下的時間記錄。你們之後能夠根據這個記錄，預估本身的elasticsearch shard分配會須要多少時間。

動態修改 master選舉數量。根據elasticsearch文檔推薦的公式： (N(master)+1)/2

curl -XPUT es1_ip:9200/_cluster/settings -d '{
      "persistent" : {
          "discovery.zen.minimum_master_nodes" : 3
      }
    }'

檢查配置：

{"persistent":{"discovery":{"zen":{"minimum_master_nodes":"3"}}},"transient":{"cluster":{"routing":{"allocation":{"enable":"all"}}}}}

再檢測API命令

curl es1_ip:9200/_cat/health

curl es1_ip:9200/_cat/indices

curl es1_ip:9200/_cat/shards

這時候，觀察到shard分配的結果是，每一個索引有10個shard，每一個es服務器擁有一個索引的兩個shard。新加入的es四、es5上都是副本shard，原有集羣中的es一、es二、es3擁有主shard和副本shard。

例子：

index              shard   prirep   state     docs     store  ip    node
posts               2       r       STARTED   993718   3.5gb es1_ip es1
posts               2       p       STARTED   993718   3.5gb es1_ip es1
posts               0       p       STARTED   993428   3.7gb es2_ip es2
posts               0       p       STARTED   993428   3.7gb es2_ip es2
posts               3       p       STARTED   993653   3.6gb es3_ip es3
posts               3       p       STARTED   993653   3.6gb es3_ip es3
posts               1       r       STARTED   994063   3.5gb es4_ip es4
posts               1       r       STARTED   994063   3.5gb es4_ip es4
posts               4       r       STARTED   993938   3.5gb es5_ip es5
posts               4       r       STARTED   993938   3.5gb es5_ip es5

posts索引的十個shard分片在每臺elasticsearch服務器上有兩個分片。perfect!(實際結果是亂序的)

後悔的操做選擇

咱們修改了es1的配置文件，想要重啓es1 elasticsearch實例。重啓後，發生了意想不到的事情，索引的shard又開始分配移動，等了快40分鐘分配移動結束，可是，這時候不是每一個es服務器平均擁有一個索引的兩個shard，而是有的es服務器有該索引的三個shard。

posts               2 r STARTED   993718   3.5gb es4_ip es4
posts               2 p STARTED   993718   3.5gb es2_ip es2
posts               0 p STARTED   993428   3.7gb es4_ip es4
posts               0 r STARTED   993428   3.7gb es1_ip es1
posts               3 r STARTED   993653   3.6gb es1_ip es1
posts               3 p STARTED   993653   3.6gb es2_ip es2
posts               1 r STARTED   994063   3.5gb es5_ip es5
posts               1 p STARTED   994063   3.5gb es1_ip es1
posts               4 r STARTED   993938   3.5gb es5_ip es5
posts               4 p STARTED   993938   3.5gb es3_ip es3

posts在elasticsearch1 上出現了三個shard

實際上，本來集羣中的三臺服務器是不用重啓的，你能夠修改他們elasticsearch.yml 配置中的單撥數組設置：discovery.zen.ping.unicast.hosts。加上新加的兩臺服務器的ip，和 discovery.zen.minimum_master_nodes:3。下次重啓的時候，就會讀取這個新的配置，而不須要立刻從新。由於，k能夠經過調用API的方式，動態配置discovery.zen.minimum_master_nodes，而discovery.zen.ping.unicast.hosts的配置，在新的elasticsearch服務器上配置五臺服務器的ip地址就能夠了。

打開全部es服務器的monit，測試線上elasticsearch搜索功能

修改項目代碼，加上新加的兩臺elasticsearch服務器IP

 7 個贊