關閉數據平衡

當我們試圖關閉一個節點時，ES會立即試圖復制這個節點中的數據到集群中其他節點上，這個過程會造成大量的IO請求，在關閉該節點的時候可以通過設置一下參數來避免此問題的發生：

curl -X PUT "localhost:9200/_cluster/settings" -H 'Content-Type: application/json' -d' {"persistent": {"cluster.routing.allocation.enable": "none"} }

transient與persistent的區別見：這里
僅僅做這一步還是不夠的，即使數據沒有發生變化，仍然會出現大量主副分片之間的數據拷貝。原因是在于recovery是簡單的對比主副分片的segment file（分段文件）來判斷哪些數據一致是可以本地恢復，哪些不一致的需要重新拷貝的。而不同節點的segment file是完全獨立運行的，這可能導致主副本merge的深度不完全一致，從而造成及時文檔集完全一樣，而產生的segment file卻不完全一樣。
因此通過synced flush（同步刷新）為對應的shard加入一個synced flush id，這樣在節點重啟后，先對比主副shard的synced flush id，就可以知道兩個shard是否完全相同，避免了不必要的segment file拷貝。

同步刷新

執行同步刷新，當停止一個索引時，分片的恢復會很快，所以要進行同步刷新請求：

POST _flush/synced

當有分片在集群重啟過程中并沒有發生更新，則跳過對這些分片的同步校驗，提高分片恢復的速度。
原理是當沒有索引操作時，id 標記會添加到分片上。標記可以作為一個快速的方式來檢查兩個分片的lucene索引一致是否一致；這種快速的id 比較主要用于 數據恢復或者重啟后跳過第一個也是成本最高的階段；這種情況下，segment 不需要copy，事務日志的重演會立即執行；當id 標記和flush 一起用的時候，事物日志很可能為空，更加加速了數據的恢復；
盡管很方便，但是有一些警告:

同步刷新是個盡最大努力的操作：任何正在執行索引的操作都會造成同步刷新失敗；這就一位置有些分片可能刷新成功，而有些分片則刷新失敗；

同步id 的標記在再次刷新是會移除掉；

這是因為刷新會替換低級別的儲存標記的lucene 提交點；事物日志中未提交的操作不會移除id 標記；現實中，在任何時間，應該把索引操作視觸發的移除標記為刷新一樣；
note：有索引操作時，請求同步刷新是無害的；當索引空閑時同步刷新成功，否則失敗；任何請求成功的同步刷新在數據恢復時更加迅速；

synced flush只對冷索引有效，對于熱索引（5分鐘內有更新的索引）無效，如果重啟的節點包含有熱索引，那還是免不了大量的拷貝。

關閉和升級所有節點

停止在集群中的所有節點上的服務。每一個節點都要進行單獨升級。這個主要就是文件替換操作，注意保留日志記錄。

啟動集群

先啟動master節點，然后在啟動data節點。

等待集群變為yellow

當節點加入集群中后，它首先恢復存儲在本地的主分片數據。最初的時候，通過_cat/health請求發現集群的狀態是紅色，意味著不是所有的主分片都已分配。當每個節點主分片恢復完后，集群的狀態將會變成yellow，這意味著所有主分片已經分配，而副本分片沒有被分配。

分配副本分片

延遲副本的分配直到所有節點都加入集群，在集群的所有節點，可以重新啟用副本分配：

curl -X PUT "localhost:9200/_cluster/settings" -H 'Content-Type: application/json' -d' {"persistent": {"cluster.routing.allocation.enable": "all"} }

這個時候集群將開始復制所有副本到數據節點上，這樣可以安全恢復索引和搜索，如果能延遲索引和搜索直到所有的分片已經恢復，這樣可以加快集群的恢復。

總結

以上是生活随笔為你收集整理的ElasticSearch重启策略的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。