搜尋引擎 升級 Elasticsearch 叢集數量實戰記錄

現在線上有一個elasticsearch叢集搜尋服務有三臺elasticsearch例項（es1、es2、es3），打算將其升級為5臺（增加es4、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分配功能

關閉es1、es2、es3上的monit

sudo service monit stop

手動控制elasticsearch程序的啟動，避免monit自動拉起elasticsearch程序導致意外問題

這時，新的兩臺伺服器es4、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現在的分佈情況，應該只分布在es1、es2、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。新加入的es4、es5上都是副本shard，原有叢集中的es1、es2、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