搜索引擎 升級 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