elasticsearch技術總結(二) 集群管理

2021-08-17 01:24:46 字數 1510 閱讀 6795

所謂集群管理是指集群搭建好後的日常維護和管理。

一 集群健康

集群狀態分為三種:

green : 所有主分片以及副分片都可用;

yellow:部分副本不可用;

red:丟失分片

其中集群狀態為 green 和 yellow ,集群正常,資料完整;狀態為red部分資料丟失,分配到缺失分片的操作會有異常;

集群狀態以及分片狀況可以通過kibana檢視, 也可以通過下列命令檢視

get _cluster/health
結果如下:

其中cluster_name 為集群名稱,status狀態為green;number_of_nodes 節點個數為6;

二 節點重啟

當修改配置檔案,需要重啟來生效時,而又不想影響集群的正常使用,可以按照下列方法

首先設定集群禁止分片

put /_cluster/settings

}

然後,重啟節點,重啟後,恢復集群分片,如下設定

put /_cluster/settings

}

因為正常情況下,elasticsearch 希望你的資料被完全的複製和均衡的分布。如果你手動關閉了乙個節點,集群會立刻發現節點的丟失並開始再平衡。如果節點的維護是短期工作的話,這一點就很煩人了,因為大型分片的再平衡需要花費相當的時間(想想嘗試複製 1tb 的資料——即便在高速網路上也是不一般的事情了)。

三 推遲分片

上述是乙個手動設定集群是否分片的過程,這裡要講的是,在一定的時間內延遲分片。

設定如下:

put /_all/_settings 

}

預設情況,集群會等待一分鐘來檢視節點是否會重新加入,如果這個節點在此期間重新加入,重新加入的節點會保持其現有的分片資料,不會觸發新的分片分配。更改這個時間,達到你想要的效果。例如我們將時間設定成15分鐘,在分鐘之內,都不會觸發新的分片;當然,失聯節點的主分片對應的副本會被提拔成主分片

如果節點在規定的時間內重新連線,首先會檢查本地節點的資料是否是最新,如果最新則集群狀態很快從yellow恢復到green;所以在延遲分片或者重啟節點,最好不要寫入資料;

如果節點在超時之後再回來,且集群還沒有完成分片的移動,會發生什麼事情呢?在這種情形下,elasticsearch 會檢查該機器磁碟上的分片資料和當前集群中的活躍主分片的資料是不是一樣 — 如果兩者匹配,說明沒有進來新的文件,包括刪除和修改 — 那麼 master 將會取消正在進行的再平衡並恢復該機器磁碟上的資料。

之所以這樣做是因為本地磁碟的恢復永遠要比網路間傳輸要快,並且我們保證了他們的分片資料是一樣的,這個過程可以說是雙贏。

elasticsearch技術總結(一) 集群分片

一 分片概念以及設定 分片概念 乙個 分片 是乙個底層的 工作單元 它僅儲存了全部資料中的一部分。我們往 elasticsearch 新增資料時需要用到索引 儲存相關資料的地方。索引實際上是指向乙個或者多個物理 分片 的 邏輯命名空間。分片分為主分片和副本,數量可以設定。舉個例子 假設elastic...

elasticsearch配置詳解

elasticsearch的config資料夾裡面有兩個配置檔案 elasticsearch.yml和logging.yml,第乙個是es的基本配置檔案,第二個是日誌配置檔案,es也是使用log4j來記錄日誌的,所以logging.yml裡的設定按普通log4j配置檔案來設定就行了。下面主要講解下e...

誰在使用Elasticsearch

github github使用elasticsearch搜尋20tb的資料,包括13億的檔案和1300億行的 這個不用介紹了吧,碼農們都懂的,github在2013年1月公升級了他們的 搜尋,由solr轉為elasticsearch,目前集群規模為26個索引儲存節點和8個客戶端節點 負責處理搜尋請求...