干貨 | Elasticsearch 集群健康值紅色終極解決方案【轉】

題記

Elasticsearch當清理緩存（ echo 3 > /proc/sys/vm/drop_caches ）的時候，出現 
如下集群健康值：red，紅色預警狀態，同時部分分片都成為灰色。 
 
查看Elasticsearch啟動日志會發現如下： 
集群服務超時連接的情況。

bserver: timeout notification from cluster service. timeout setting [1m], time since start [1m]

該問題排查耗時很長，問題已經解決。 
特將問題排查及解決方案詳盡的整理出來。

1、集群狀態解讀

head插件會以不同的顏色顯示。 
1）、綠色——最健康的狀態，代表所有的主分片和副本分片都可用； 
2）、黃色——所有的主分片可用，但是部分副本分片不可用； 
3）、紅色——部分主分片不可用。（此時執行查詢部分數據仍然可以查到，遇到這種情況，還是趕快解決比較好。） 
參考官網：http://t.cn/RltLEpN（部分中文集群健康狀態博文資料翻譯的不夠精確，以官網為准）

如果集群狀態為紅色， Head插件顯示：集群健康值red 。則說明：至少一個主分片分配失敗。

這將導致一些數據以及索引的某些部分不再可用。

盡管如此， ElasticSearch還是允許我們執行查詢，至於是通知用戶查詢結果可能不完整還是掛起查詢，則由應用構建者來決定。

2、什么是unassigned 分片？

一句話解釋：未分配的分片。 
啟動ES的時候，通過Head插件不停刷新，你會發現集群分片會呈現紫色、灰色、最終綠色的狀態。

3、為什么會出現 unassigned 分片？

如果不能分配分片，例如，您已經為集群中的節點數過分分配了副本分片的數量，則分片將保持UNASSIGNED狀態。 
其錯誤碼為：ALLOCATION_FAILED。

你可以通過如下指令，查看集群中不同節點、不同索引的狀態。

GET _cat/shards?h=index,shard,prirep,state,unassigned.reason

4、出現unassigned 分片后的症狀？

head插件查看會：Elasticsearch啟動N長時候后，某一個或幾個分片仍持續為灰色。

5、unassigned 分片問題可能的原因？

1）INDEX_CREATED：由於創建索引的API導致未分配。 2）CLUSTER_RECOVERED ：由於完全集群恢復導致未分配。 3）INDEX_REOPENED ：由於打開open或關閉close一個索引導致未分配。 4）DANGLING_INDEX_IMPORTED ：由於導入dangling索引的結果導致未分配。 5）NEW_INDEX_RESTORED ：由於恢復到新索引導致未分配。 6）EXISTING_INDEX_RESTORED ：由於恢復到已關閉的索引導致未分配。 7）REPLICA_ADDED：由於顯式添加副本分片導致未分配。 8）ALLOCATION_FAILED ：由於分片分配失敗導致未分配。 9）NODE_LEFT ：由於承載該分片的節點離開集群導致未分配。 10）REINITIALIZED ：由於當分片從開始移動到初始化時導致未分配（例如，使用影子shadow副本分片）。 11）REROUTE_CANCELLED ：作為顯式取消重新路由命令的結果取消分配。 12）REALLOCATED_REPLICA ：確定更好的副本位置被標定使用，導致現有的副本分配被取消，出現未分配。

6、集群狀態紅色如何排查？

症狀：集群健康值紅色; 
日志：集群服務連接超時； 
可能原因：集群中部分節點的主分片未分配。 
接下來的解決方案主要圍繞：使主分片unsigned 分片完成再分配展開。

7、如何Fixed unassigned 分片問題？

方案一：極端情況——這個分片數據已經不可用，直接刪除該分片。 
ES中沒有直接刪除分片的接口，除非整個節點數據已不再使用，刪除節點。 
curl -XDELETE ‘localhost:9200/index_name/’

方案二：集群中節點數量>=集群中所有索引的最大副本數量 +１。 
N> = R + 1 
其中： 
N——集群中節點的數目； 
R——集群中所有索引的最大副本數目。 
知識點：當節點加入和離開集群時，主節點會自動重新分配分片，以確保分片的多個副本不會分配給同一個節點。換句話說，主節點不會將主分片分配給與其副本相同的節點，也不會將同一分片的兩個副本分配給同一個節點。 
如果沒有足夠的節點相應地分配分片，則分片可能會處於未分配狀態。 
由於我的集群就一個節點，即Ｎ＝１；所以Ｒ＝０，才能滿足公式。

問題就轉嫁為： 
１）添加節點處理，即Ｎ增大； 
２）刪除副本分片，即R置為0。 
R置為0的方式，可以通過如下命令行實現：

root@tyg:/# curl -XPUT "http://localhost:9200/_settings" -d' { "number_of_replicas" : 0 } ' {"acknowledged":true}

方案三：allocate重新分配分片。 
如果方案二仍然未解決，可以考慮重新分配分片。

可能的原因：

1）節點在重新啟動時可能遇到問題。正常情況下，當一個節點恢復與群集的連接時，它會將有關其分片的信息轉發給主節點，然后主節點將這分片從“未分配”轉換為“已分配/已啟動”。

2）當由於某種原因（例如節點的存儲已被損壞）導致該進程失敗時，分片可能保持未分配狀態。

在這種情況下，您必須決定如何繼續：嘗試讓原始節點恢復並重新加入集群（並且不要強制分配主分片）；

或者強制使用Reroute API分配分片並重新索引缺少的數據原始數據源或備份。 
如果您決定分配未分配的主分片，請確保將“allow_primary”：“true”標志添加到請求中。

ES5.X使用腳本如下：

NODE="YOUR NODE NAME" IFS=$'\n' for line in $(curl -s 'localhost:9200/_cat/shards' | fgrep UNASSIGNED); do INDEX=$(echo $line | (awk '{print $1}')) SHARD=$(echo $line | (awk '{print $2}')) curl -XPOST 'localhost:9200/_cluster/reroute' -d '{ "commands": [ { " allocate_replica ": { "index": "'$INDEX'", "shard": '$SHARD', "node": "'$NODE'", "allow_primary": true } } ] }' done

 

—————————————————————————————