升級 Elasticsearch 叢集數量實戰記錄
搜尋引擎 升級 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
7 個贊