白話Elasticsearch66-針對集群重啟時的shard恢復耗時過長問題定制的重要參數

文章目錄

概述

集群重啟時的無意義shard重分配問題

shard recovery配置

概述

繼續跟中華石杉老師學習ES，第66篇

課程地址： https://www.roncoo.com/view/55

集群重啟時的無意義shard重分配問題

在集群重啟的時候，有一些配置會影響shard恢復的過程。

首先，我們需要理解默認配置下，shard恢復過程會發生什么事情。

如果我們有10個node，每個node都有一個shard，可能是primary shard或者replica shard，你有一個index，有5個primary shard，每個primary shard有一個replica shard。

如果我們將整個集群關閉了進行一些維護性的操作，比如給機器安裝新的磁盤之類的事情。當我們重啟集群的時候，肯定節點是一個接一個的啟動的，可能會出現5個節點先啟動了，然后剩下5個節點還沒啟動。

也許是因為剩下的5個節點沒來得及啟動，或者是因為一些原因耽擱了，總之不管是什么原因，就是現在只有5個節點是在線的。這5個節點會通過gossip協議互相通信，選舉出一個master，然后組成一個集群。他們會發現數據沒有被均勻的分布，因為有5個節點沒有啟動，那么那5個節點上的shard就是不可用的，集群中就少了一半的shard。此時在線的5個node就會將部分replica shard提升為primary shard，同時為每個primary shard復制足夠的replica shard。

最后，可能剩下的5個節點加入了集群。但是這些節點發現本來是他們持有的shard已經被重新復制并且放在之前的5個node之中了，此時他們就會刪除自己本地的數據。然后集群又會開始進行shard的rebalance操作，將最早啟動的5個node上的shard均勻分布到后來啟動的5個node上去。

在這個過程中，這些shard重新復制，移動，刪除，再次移動的過程，會大量的耗費網絡和磁盤資源。對于數據量龐大的集群來說，可能導致每次集群重啟時，都有TB級別的數據無端移動，可能導致集群啟動會耗費很長時間。但是如果所有的節點都可以等待整個集群中的所有節點都完全上線之后，所有的數據都有了以后，再決定是否要復制和移動shard，情況就會好很多。

shard recovery配置

所以現在問題我們已經知道了，那么我們就可以配置一些設置來解決這個問題。

首先我們需要設置一個參數，gateway.recover_after_nodes: 8。

這個參數可以讓es直到有足夠的node都上線之后，再開始shard recovery的過程。所以這個參數是跟具體的集群相關的，要根據我們的集群中節點的數量來決定。

此外，還應該設置一個集群中至少要有多少個node，等待那些node的時間：gateway.expected_nodes: 10，gateway.recover_after_time: 5m。

經過上面的配置之后，es集群的行為會變成下面這樣，

等待至少8個節點在線，然后等待最多5分鐘，或者10個節點都在線，開始shard recovery的過程。

這樣就可以避免少數node啟動時，就立即開始shard recovery，消耗大量的網絡和磁盤資源，甚至可以將shard recovery過程從數小時縮短為數分鐘。

elasticsearch

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。