elasticsearch技術總結(二)-叢集管理
所謂叢集管理是指叢集搭建好後的日常維護和管理。
一 叢集健康
叢集狀態分為三種:
green : 所有主分片以及副分片都可用;
yellow:部分副本不可用;
red:丟失分片
其中叢集狀態為 green 和 yellow ,叢集正常,資料完整;狀態為red部分資料丟失,分配到缺失分片的操作會有異常;
叢集狀態以及分片狀況可以通過kibana檢視, 也可以通過下列命令檢視
GET _cluster/health
結果如下:
{ "cluster_name": "cluster_name_example", "status": "green", "timed_out": false, "number_of_nodes": 6, "number_of_data_nodes": 6, "active_primary_shards": 64, "active_shards": 132, "relocating_shards": 0, "initializing_shards": 0, "unassigned_shards": 0, "delayed_unassigned_shards": 0, "number_of_pending_tasks": 0, "number_of_in_flight_fetch": 0, "task_max_waiting_in_queue_millis": 0, "active_shards_percent_as_number": 100 }
其中cluster_name 為叢集名稱,status狀態為green;number_of_nodes 節點個數為6;
二 節點重啟
當修改配置檔案,需要重啟來生效時,而又不想影響叢集的正常使用,可以按照下列方法
首先設定叢集禁止分片
PUT /_cluster/settings
{
"transient" : {
"cluster.routing.allocation.enable" : "none"
}
}
然後,重啟節點,重啟後,恢復叢集分片,如下設定
PUT /_cluster/settings
{
"transient" : {
"cluster.routing.allocation.enable" : "all "
}
}
因為正常情況下,Elasticsearch 希望你的資料被完全的複製和均衡的分佈。如果你手動關閉了一個節點,叢集會立刻發現節點的丟失並開始再平衡。如果節點的維護是短期工作的話,這一點就很煩人了,因為大型分片的再平衡需要花費相當的時間(想想嘗試複製 1TB 的資料——即便在高速網路上也是不一般的事情了)。
三 推遲分片
上述是一個手動設定叢集是否分片的過程,這裡要講的是,在一定的時間內延遲分片。
設定如下:
PUT /_all/_settings { "settings": { "index.unassigned.node_left.delayed_timeout": "15m" } }
預設情況,叢集會等待一分鐘來檢視節點是否會重新加入,如果這個節點在此期間重新加入,重新加入的節點會保持其現有的分片資料,不會觸發新的分片分配。更改這個時間,達到你想要的效果。例如我們將時間設定成15分鐘,在分鐘之內,都不會觸發新的分片;當然,失聯節點的主分片對應的副本會被提拔成主分片;
如果節點在規定的時間內重新連線,首先會檢查本地節點的資料是否是最新,如果最新則叢集狀態很快從yellow恢復到green;所以在延遲分片或者重啟節點,最好不要寫入資料;
如果節點在超時之後再回來,且叢集還沒有完成分片的移動,會發生什麼事情呢?在這種情形下,Elasticsearch 會檢查該機器磁碟上的分片資料和當前叢集中的活躍主分片的資料是不是一樣 — 如果兩者匹配,說明沒有進來新的文件,包括刪除和修改 — 那麼 master 將會取消正在進行的再平衡並恢復該機器磁碟上的資料。
之所以這樣做是因為本地磁碟的恢復永遠要比網路間傳輸要快,並且我們保證了他們的分片資料是一樣的,這個過程可以說是雙贏。
如果分片已經產生了分歧(比如:節點離線之後又索引了新的文件),那麼恢復程序會繼續按照正常流程進行。重新加入的節點會刪除本地的、過時的資料,然後重新獲取一份新的。
推遲分片可以解決上一篇中節點偶爾失聯的問題。