1. 程式人生 > >elasticsearch 資料儲存策略

elasticsearch 資料儲存策略

(備註:以下均為6.3.0版本elasticsearch測試結果)

新建索引  —>  分片劃分(按節點均衡分配)—>  儲存目錄(均衡分配分片)

一   節點對分片均勻分佈,若分佈不平衡,則會自動遷移

如:新增一節點,則會從遷移分片到新節點 直到重新達到平衡,此過程為叢集的再均衡

例:967個分片在三個節點中的分配

導致叢集自發再平衡過程的原因如下:

  1. 新增節點
  2. 某一個節點失聯,或下線

可能會發生如下過程:

  1. Node(節點) 19 在網路中失聯了(某個傢伙踢到了電源線)
  2. Master 立即注意到了這個節點的離線,它決定在叢集內提拔其他擁有 Node 19 上面的主分片對應的副本分片為主分片
  3. 在副本被提拔為主分片以後,master 節點開始執行恢復操作來重建缺失的副本。叢集中的節點之間互相拷貝分片資料,網絡卡壓力劇增,叢集狀態嘗試變綠。
  4. 由於目前叢集處於非平衡狀態,這個過程還有可能會觸發小規模的分片移動。其他不相關的分片將在節點間遷移來達到一個最佳的平衡狀態

通常情況下,上述過程是需要的,比如新增節點,比如下線一個節點,但在某些情況下,臨時失聯可以很快恢復的情況下會造成一些麻煩。

比如:

踢到電源線的倒黴管理員,把伺服器插好電源線進行了重啟,現在節點 Node 19 又重新加入到了叢集。不幸的是,這個節點被告知當前的資料已經沒有用了, 資料已經在其他節點上重新分配了。所以 Node 19 把本地的資料進行刪除,然後重新開始恢復叢集的其他分片(然後這又導致了一個新的再平衡)

解決方案:

修改預設等待時間,delayed_timeout為0則為立即分配,5m位等待5分鐘

PUT /_all/_settings

{

  "settings": {

    "index.unassigned.node_left.delayed_timeout": "5m"

  }

}

注意:

延遲分配不會阻止副本被提拔為主分片。叢集還是會進行必要的提拔來讓叢集回到 yellow狀態。缺失副本的重建是唯一被延遲的過程。

二 同一節點不同資料目錄間的平衡

如配置有path.data: /data/es/data,/data1/es/data,/data1/es/data2,即同一節點有三個資料目錄

通常情況下,

  1. 三個目錄均勻寫入分片
  2. 資料不會做再平衡,即目錄間資料不會做自發遷移
  3. 每個目錄狀態是一致的,都具有本節點所有索引的資料目錄和狀態資訊
  4. 每個索引目錄的名稱為該索引的uuid
  5. 節點在新建分片時將盡可能將分片儲存在空閒空間更多的資料目錄下,只能重新達到平衡

節點資料:

indices 為資料儲存目錄,_state為節點狀態目錄

UAQVT_zRRsaStHEmtPAnfg為節點uuid

global-364.st為叢集全域性狀態檔案

node.lock檔案用於確保一次只能從一個數據目錄讀取/寫入

索引資料:

目錄名為索引uuid,uuid可以在kibana的索引管理介面檢視,也可以用api檢視

GET /_cat/indices?v 可以檢視所有索引的資訊

此目錄為 索引id為6qrebTS8RWa81xxTIaFKRg的分片4儲存目錄,

_stat為此索引的狀態資訊

index目錄為分片4的索引資料,_state目錄為此分片的狀態資訊,translog目錄為此分片的操作日誌

目錄對應磁碟空間不同時:

如上所示,data目錄和data1目錄分屬不通硬碟

需要注意的是:

  1. 依照path.data配置目錄,叢集儘可能保證各個目錄分片分佈均衡
  2. 叢集不會自動在目錄間遷移資料,只會在新建分片時儘可能往空閒節點分配
  3. 目錄間分配是以分片數計數,也即是不同目錄最終達成分片數一致
  4. 如果各個目錄儲存空間不同,叢集無法自動識別

如上所述,如果兩個硬碟空間不同,如/data目錄 容量是 /data1的一半左右

若不做處理,在每個目錄下分配一個es目錄,會造成資料分佈不平衡

解決方案:在/data1中分配兩個es資料目錄

此操作仍然會造成一些問題,比如叢集在統計剩餘容量時,對/data1計算了兩次

如:

但實際上剩餘容量為:66G+339G~400G,而不是66G+339G+339G~740G

因此儘可能保證不同目錄容量空間一致