Elasticsearch(ES)生產集羣健康狀況爲黃色(yellow)的官方詳細解釋、原因分析和解決方案(實測可用)

 

介紹

  Elasticsearch(ES)集羣狀態顯示黃色時,使用cerebro會提示顯示黃色原因,如果使用其他工具,則可以通過健康檢查api查看集羣狀態GET /_cluster/health
cerebro監控elasticsearch集羣爲黃色

調用健康檢查apiGET /_cluster/health反饋如下信息:

{
  "cluster_name" : "troll*",
  "status" : "yellow",
  "timed_out" : false,
  "number_of_nodes" : ***,
  "number_of_data_nodes" : ***,
  "active_primary_shards" : ***,
  "active_shards" : ***,
  "relocating_shards" : ***,
  "initializing_shards" : ***,
  "unassigned_shards" : ***, // ~注意看這裏~
  "delayed_unassigned_shards" : ***,
  "number_of_pending_tasks" : ***,
  "number_of_in_flight_fetch" : ***,
  "task_max_waiting_in_queue_millis" : ***,
  "active_shards_percent_as_number" : ***
}

elasticsearch健康裝填查詢接口/_cluster/health接口反饋內容解釋如下:

  • 響應正文
  • cluster_name
    (字符串)集羣的名稱。
  • status
    (字符串)集羣的運行狀況,基於其主要和副本分片的狀態。狀態爲:
      – green
      所有分片均已分配。
      – yellow
      所有主分片均已分配,但未分配一個或多個副本分片。如果羣集中的某個節點發生故障,則在修復該節點之前,某些數據可能不可用。
      – red
      未分配一個或多個主分片,因此某些數據不可用。在集羣啓動期間,這可能會短暫發生,因爲已分配了主要分片。
  • timed_out
    (布爾值)如果false響應在timeout參數指定的時間段內返回(30s默認情況下)。
  • number_of_nodes
    (整數)集羣中的節點數。
  • number_of_data_nodes
    (整數)作爲專用數據節點的節點數。
  • active_primary_shards
    (整數)活動主分區的數量。
  • active_shards
    (整數)活動主分區和副本分區的總數。
  • relocating_shards
    (整數)正在重定位的分片的數量。
  • initializing_shards
    (整數)正在初始化的分片數。
  • unassigned_shards
    (整數)未分配的分片數。
  • delayed_unassigned_shards
    (整數)其分配因超時設置而延遲的分片數。
  • number_of_pending_tasks
    (整數)尚未執行的集羣級別更改的數量。
  • number_of_in_flight_fetch
    (整數)未完成的訪存數量。
  • task_max_waiting_in_queue_millis
    (整數)自最早的初始化任務等待執行以來的時間(以毫秒爲單位)。
  • active_shards_percent_as_number
    (浮動)羣集中活動碎片的比率,以百分比表示。

問題分析

查看集羣狀態

# 查看集羣健康狀態
GET /_cluster/health

查看集羣分片的情況,重點關注unassigned_shards沒有正常分配的副本數量。

{
“cluster_name” : “*******”,
“status” : “yellow”,
“timed_out” : false,
“number_of_nodes” : *******,
“number_of_data_nodes” : *******,
“active_primary_shards” : *******,
“active_shards” : *******,
“relocating_shards” : *******,
“initializing_shards” : *******,
“unassigned_shards” : *******,
“delayed_unassigned_shards” : *******,
“number_of_pending_tasks” : *******,
“number_of_in_flight_fetch” : *******,
“task_max_waiting_in_queue_millis” : *******,
“active_shards_percent_as_number” : *******
}

找到問題索引

# 查看索引情況
GET _cat/indices
  • 1
  • 2

根據返回值找到異常索引

yello open 索引名 ***** ***** ***** ***** ***** ***** *****

查看詳細的異常信息

# 查看異常原因
GET /_cluster/allocation/explain

查看分片異常的原因,這裏提示異常原因爲:unassignednode_leftthe shard cannot be allocated to the same node on which a copy of the shard already existscannot allocate because allocation is not permitted to any of the nodes,此處是由於節點丟失導致無法進行副本複製導致。

{
“index” : “",
“shard” : "
”,
“primary” : “",
“current_state” : “unassigned”,
“unassigned_info” : {
“reason” : “NODE_LEFT”,
“at” : “2020-05-15T06:12:23.967Z”,
“details” : “node_left [KyZROB7BSASwY0i3r7q3nw]”,
“last_allocation_status” : “no_attempt”
},
“can_allocate” : “no”,
“allocate_explanation” : “cannot allocate because allocation is not permitted to any of the nodes”,
“node_allocation_decisions” : [
{
“node_id” : “FkwTKuMISlG88uNtelHQbQ”,
“node_name” : “es7_01”,
“transport_address” : “172.21.0.6:9300”,
“node_attributes” : {
“ml.machine_memory” : “12566077440”,
“ml.max_open_jobs” : “20”,
“xpack.installed” : “true”
},
“node_decision” : “no”,
“deciders” : [
{
“decider” : “same_shard”,
“decision” : “NO”,
“explanation” : "the shard cannot be allocated to the same node on which a copy of the shard already exists [[
]][0], node[FkwTKuMISlG88uNtelHQbQ], [P], s[STARTED], a[id=l_k948LiTcSqjhp8PRKqVQ]]”
}
]
},
{
“node_id” : “mjNvBmkASwq0Dx6W5028Uw”,
“node_name” : “es7_03”,
“transport_address” : “172.21.:9300”,
“node_attributes” : {
“ml.machine_memory” : “12566077440”,
“ml.max_open_jobs” : “20”,
“xpack.installed” : “true”
},
“node_decision” : “no”,
“deciders” : [
{
“decider” : “same_shard”,
“decision” : “NO”,
“explanation” : “the shard cannot be allocated to the same node on which a copy of the shard already exists [[******]][0], node[mjNvBmkASwq0Dx6W5028Uw], [R], s[STARTED], a[id=lS8fqbDoRA-ju6QW5psnjA]]”
}
]
}
]
}

處理方案

步驟一、找到elasticsearch集羣異常的索引

# 查看索引信息,找出異常索引
GET /_cat/indices\?v

返回:

# health status index                    uuid                   pri rep docs.count docs.deleted store.size pri.store.size
# green  open   **                   D90ToWRGTpyeJAIy2ZVCvw   ***   ***      ***            ***     ***          ***
# yellow open   **                  hXI3lFOlSVi6gnqREZzEwQ   ***   ***          ***            ***       ***           ***
# green  open   .kibana_task_manager_1   akJZg3QkRta-oGH8BEfhXA   ***   ***          ***            ***     ***          ***
# green  open   .apm-agent-configuration f5ftL0VISRm36KXnN3QtPQ   ***   ***          ***            ***       ***           ***
# green  open   .kibana_1                d5k_3pOkRSe95Cf-dMo0SQ   ***   ***         ***            ***    ***         ***

從以上信息中可以看出第二行的索引存在異常,爲黃色(yellow),elasticsearch健康狀態爲黃色則代表所有主分片均已分配,但未分配一個或多個副本分片。如果羣集中的某個節點發生故障,則在修復該節點之前,某些數據可能不可用。則將副本集大小進行重新設置即可。

步驟二、查看es集羣健康信息,以及黃色狀態索引的settings信息進行分析

查看es集羣的健康狀態GET /_cluster/health
返回信息如下:

{
  "cluster_name" : "troll*",
  "status" : "yellow",
  "timed_out" : false,
  "number_of_nodes" : ***,
  "number_of_data_nodes" : ***,
  "active_primary_shards" : ***,
  "active_shards" : ***,
  "relocating_shards" : ***,
  "initializing_shards" : ***,
  "unassigned_shards" : ***, // ~注意看這裏~
  "delayed_unassigned_shards" : ***,
  "number_of_pending_tasks" : ***,
  "number_of_in_flight_fetch" : ***,
  "task_max_waiting_in_queue_millis" : ***,
  "active_shards_percent_as_number" : ***
}

對照返回值官方文檔解釋(如上介紹中),發現存在部分副本分片爲正常分配的情況。

查看es集羣黃色狀態索引的settings

# 查看索引設置
GET /***/_settings

反饋信息如下:

{
  "***" : {
    "settings" : {
      "index" : {
        "creation_date" : "***",
        "number_of_shards" : "***",
        "number_of_replicas" : "***",  // 關注此處的副本分片的大小
        "uuid" : "hXI3lFOlSVi6gnqREZzEwQ",
        "version" : {
          "created" : "***"
        },
        "provided_name" : "***"
      }
    }
  }
}

步驟三、分析並解決問題

此處假設number_of_replicas的數量爲3,則說明3個分片未分配。我們需要根據不同的情況進行分析:

  • 存在數個節點宕機或者誤操作的情況,導致數據丟失,或爲開啓新的副本集複製,此時若宕機節點數大於副本數時,可能導致部分數據不可用。若此時宕機數量小於副本集時,則在重建索引,或者手動啓動副本複製後正常。
    1. 重建索引命令:
      # 重建索引
      POST _reindex
      {
        "source": {
          "index": "舊索引名"
        },
        "dest": {
          "index": "新索引名"
        }
      }
      
      # 查看重建索引的設置
      GET /新索引名
      
      # 刪除索引
      DELETE /舊索引名
      
      # 創建索引別名
      POST /_aliases
      {
        "actions": [
          {
            "add": {
              "index": "新索引名",
              "alias": "舊索引名"
            }
          }
        ]
      }
    
  1. 手動進行elasticsearch集羣索引副本複製;
# 重新設置索引分片信息
PUT 索引名/_settings
{
      "number_of_replicas" : **
}
  •  
  • 4
  • 5
  • 在設置延遲複製副本集策略的生產集羣,則需要進行手工啓動複製副本集操作,以免出現數據丟失風險。

  • 重建索引或大量寫入過程中,若處於重建過程中,則黃色狀態指示暫時的,需觀察一段時間後再判斷是否有異常。

  • 當副本數大於數據節點數時,那麼每個分片只能最多有節點數量-1個副本,無法分配的副本數則爲主分片數*(副本數-(節點數-1)),例如:假設節點數爲3,主分片數爲5,副本數爲3,那麼無法分配的副本數則爲:5*(3-(3-1))=5。那麼此時只需要重新設置索引副本分片數即可,具體操作如下:

# 重新設置索引分片信息
PUT 索引名/_settings
{
      "number_of_replicas" : 2
}

執行結果如下:

{
“acknowledged” : true
}

查看修改後的索引配置

# 查看索引設置
GET /***/_settings
  • 1

執行重新設置副本分片數後,最新settings如下:

{
  "***" : {
    "settings" : {
      "index" : {
        "creation_date" : "***",
        "number_of_shards" : "***",
        "number_of_replicas" : "2",  // 關注此處的副本分片的大小已改變
        "uuid" : "hXI3lFOlSVi6gnqREZzEwQ",
        "version" : {
          "created" : "***"
        },
        "provided_name" : "***"
      }
    }
  }
}

此時再看集羣健康狀態:

{
  "cluster_name" : "troll*",
  "status" : "green",
  "timed_out" : false,
  "number_of_nodes" : ***,
  "number_of_data_nodes" : ***,
  "active_primary_shards" : ***,
  "active_shards" : ***,
  "relocating_shards" : ***,
  "initializing_shards" : ***,
  "unassigned_shards" : ***, // ~注意看這裏~
  "delayed_unassigned_shards" : ***,
  "number_of_pending_tasks" : ***,
  "number_of_in_flight_fetch" : ***,
  "task_max_waiting_in_queue_millis" : ***,
  "active_shards_percent_as_number" : ***
}
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章