天天看點

Elasticsearch叢集管理之1——如何高效的添加、删除節點?

Elasticsearch叢集管理之1——如何高效的添加、删除節點?
連結

1.2 删除節點問題

假設叢集中有5個節點,我必須在運作時删除2個節點。 那麼如何在不影響指數的情況下完成?

我有接近10 Gbp/hour的連續資料流,這些資料正在連續寫入并索引化。 重新平衡會對此有所影響嗎?

本文就從上面兩個問題說起,将相關知識點串起來,内容較長,閱讀時間5分鐘+。

2、知識點

2.1 Master節點的職責

主節點的主要作用之一是确定将哪些分片配置設定給哪些節點,以及何時在節點之間移動分片以重新平衡叢集。

2.2 分片配置設定發生的時機

分片配置設定是将分片配置設定給節點的過程。 這可能發生在叢集初始恢複,副本配置設定,重新平衡或添加或删除節點期間。

2.3 控制配置設定/重新平衡分片操作的常見設定

2.3.1 配置設定分片設定

cluster.routing.allocation.enable

目的:啟用或禁用特定種類的分片的配置設定。

all - (預設值)允許為所有類型的分片配置設定分片。

primaries - 僅允許配置設定主分片的分片。

new_primaries -僅允許為新索引的主分片配置設定分片。

none - 任何索引都不允許任何類型的配置設定分片。

重新啟動節點時,此設定不會影響本地主分片的恢複。

假設重新啟動的節點的配置設定ID與群集狀态中的某個活動配置設定ID比對,若該節點具有未配置設定的主分片的副本,則會立即恢複該主分片,

2.3.2 平衡分片設定

cluster.routing.rebalance.enable

目的:為特定類型的分片啟用或禁用重新平衡。

允許控制群集範圍内允許的并發分片重新平衡數。預設為2.請注意,此設定僅控制由于群集中的不平衡而導緻的并發分片重定位數。此設定不會因配置設定過濾或強制感覺而限制分片重定位。

2.3.3 權重因子設定

cluster.routing.allocation.balance.shard

目的:定義節點(float)上配置設定的分片總數的權重因子。預設為0.45f。提高這一點會增加均衡群集中所有節點的分片數量的趨勢。

cluster.routing.allocation.balance.index

目的:定義在特定節點(float)上配置設定的每個索引的分片數量的權重因子。預設為0.55f。提高這一點會增加在叢集中所有節點上均衡每個索引的分片數的趨勢。

cluster.routing.allocation.balance.threshold

目的:應執行的操作的最小優化值(非負浮點數)。預設為1.0f。提高此選項将導緻群集在優化分片平衡方面不那麼積極。

2.4 基于磁盤的分片配置設定

在确定是将新分片配置設定給該節點還是主動從該節點拷貝分片到其他節點之前,Elasticsearch會考慮節點上的可用磁盤空間。

2.5 磁盤的三個預設警戒水位線

cluster.routing.allocation.disk.watermark.low

低警戒水位線——預設為磁盤容量的85%。

Elasticsearch不會将分片配置設定給使用磁盤超過85%的節點。它也可以設定為絕對位元組值(如500mb),以防止Elasticsearch在小于指定的可用空間量時配置設定分片。此設定不會影響新建立的索引的主分片,或者特别是之前任何從未配置設定過的分片。

cluster.routing.allocation.disk.watermark.high

高警戒水位線——預設為磁盤容量的90%。

Elasticsearch将嘗試從磁盤使用率超過90%的節點重新配置設定分片。它也可以設定為絕對位元組值,以便在節點小于指定的可用空間量時将其從節點重新配置設定。此設定會影響所有分片的配置設定,無論先前是否配置設定。

cluster.routing.allocation.disk.watermark.flood_stage

洪水警戒水位線——預設為磁盤容量的95%。

Elasticsearch對每個索引強制執行隻讀索引塊(index.blocks.read_only_allow_delete)。這是防止節點耗盡磁盤空間的最後手段。一旦有足夠的可用磁盤空間允許索引操作繼續,就必須手動釋放索引塊。

cluster.info.update.interval

Elasticsearch應該多久檢查一次群集中每個節點的磁盤使用情況。 預設為30秒。

磁盤的分片配置設定綜合樣例配置如下:

PUT _cluster/settings

{

 "transient": {

   "cluster.routing.allocation.disk.watermark.low": "100gb",

   "cluster.routing.allocation.disk.watermark.high": "50gb",

   "cluster.routing.allocation.disk.watermark.flood_stage": "10gb",

   "cluster.info.update.interval": "1m"

 }

}

1

2

3

4

5

6

7

8

9

2.6 索引/節點層面的分片配置設定

可用的動态叢集設定如下,其中{attribute}指的是任意節點屬性:

cluster.routing.allocation.include.{attribute}——至少包含

cluster.routing.allocation.require.{attribute}——全部包含

cluster.routing.allocation.exclude.{attribute}——非、排除操作

3、添加節點

添加注意事項:

ES必須版本号一緻,舉例:Elasticsearch V6.4.1。

和新配置過Elasticsearch節點一緻,以下僅介紹最快的方法。

步驟1:拷貝原有節點的ES相關檔案到新機器。

步驟2:修改核心配置檔案jvm.options和elasticsearch.yml。

注意1:jvm注意結合實際機器的記憶體進行合理化配置。取值:Min(32GB,機器記憶體一半)。

注意2:根據配置設定的角色(Master/data/client)配置。

注意3:叢集名稱必須和預先的機器一緻。

注意4:避免腦裂,合理化如下配置

curl -XPUT 'localhost:9200/_cluster/settings' -d'

   "discovery.zen.minimum_master_nodes": 3

注意5:啟動報錯,根據出錯做相關修改。

步驟3:通路9200端口驗證成功與否。

4、删除節點

注意事項:

1、節點數目少的時候,一定要注意腦裂問題。

2、腦裂問題必要的時候需要更新:elasticsearch.yml 中的 minimum_master_nodes。

4.1 方案一——停啟叢集分片自動配置設定

步驟1:暫停資料寫入程式

步驟2:關閉叢集shard allocation

#關閉叢集分片自動配置設定

 "persistent": {

   "cluster.routing.allocation.enable": "none"

步驟3:手動執行POST /_flush/synced

#打開叢集分片自動配置設定

POST /_flush/synced

步驟4:重新開機結點

步驟5:重新開啟叢集shard allocation

   "cluster.routing.allocation.enable": "all"

步驟6:等待recovery完成,叢集health status變成green

步驟7:重新開啟資料寫入程式

以上7步驟系參考Wood大叔總結。

4.2 方案二——排除停用節點

步驟1 排除停用節點

您可以通過告知群集将其從配置設定中排除來停用節點。

 "transient" : {

   "cluster.routing.allocation.exclude._ip" : "10.0.0.1"

這将導緻Elasticsearch将該節點上的分片配置設定給其餘節點,而不會将群集狀态更改為黃色或紅色(即使您的副本數設定為0)。

重新配置設定所有分片後,您可以關閉節點并執行您需要執行的任何操作。 完成後,,Elasticsearch将再剩餘節點上再次重新平衡分片。

步驟2 檢查叢集健康狀态

curl -XGET ‘http://ES_SERVER:9200/_cluster/health?pretty’

如果沒有節點relocating,則排除節點已經被安全剔除,可以考慮關閉節點。

步驟3 判定資料是否還存在

檢視節點上是否還有文檔存在。

curl -XGET ‘http://ES_SERVER:9200/_nodes/NODE_NAME/stats/indices?pretty’

上述三步,能保證節點穩妥删除。

5、小結

知識的融會貫通唯有多看、多思、多總結、多實踐。

參考:

https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-cluster.html https://elasticsearch.cn/article/38 https://elasticsearch.cn/question/5376