轉至
1.https://www.datadoghq.com/blog/elasticsearch-unassigned-shards/#reason-1-shard-allocation-is-purposefully-delayed

2.https://wklken.me/posts/2015/05/23/elasticsearch-issues.html

原因一：Shard分配被故意延遲

當節點離開集群時，主節點會暫時延遲分片重新分配，以避免在重新平衡分片上不必要地浪費資源，以防原始節點能夠在一定時間段內（默認為一分鐘）恢復。如果是這種情況，您的日志應如下所示：

[TIMESTAMP][INFO][cluster.routing] [PRIMARY NODE NAME] delaying allocation for [54] unassigned shards, next check in [1m]

您可以像這樣動態修改延遲時間：

curl -XPUT "localhost:9200/<INDEX_NAME>/_settings?pretty" -H 'Content-Type: application/json' -d' {"settings": {"index.unassigned.node_left.delayed_timeout": "5m"} }'

替換<INDEX_NAME>為_all將更新集群中所有索引的閾值。

延遲期結束后，您應該開始看到主要分配這些分片。如果沒有，請繼續閱讀以探索其他潛在原因的解決方案。

原因二：分片太多，節點不夠

當節點加入和離開集群時，主節點會自動重新分配分片，確保分片的多個副本不會分配給同一個節點。換句話說，主節點不會將主分片分配給與其副本相同的節點，也不會將同一分片的兩個副本分配給同一節點。如果沒有足夠的節點來相應地分配分片，分片可能會處于未分配狀態。

為避免此問題，請遵循以下公式，確保集群中的每個索引初始化時每個主分片的副本數少于集群中的節點數：

N >= R + 1

其中 N 是集群中的節點數，R 是集群中所有索引的最大分片復制因子。

在下面的屏幕截圖中，many-shards索引存儲在四個主分片上，每個主分片有四個副本。索引的 20 個分片中有 8 個未分配，因為我們的集群僅包含三個節點。尚未分配每個主分片的兩個副本，因為三個節點中的每一個都已包含該分片的副本。
要解決此問題，您可以向集群添加更多數據節點或減少副本數量。在我們的例子中，我們要么需要在集群中添加至少兩個節點或者 將復制因子減少到兩個，如下所示：

curl -XPUT "localhost:9200/<INDEX_NAME>/_settings?pretty" -H 'Content-Type: application/json' -d' { "number_of_replicas": 2 }'

原因3：您需要重新啟用分片分配

默認情況下，所有節點上都啟用了分片分配，但您可能在某些時候禁用了分片分配（例如，為了執行滾動重啟），而忘記重新啟用它。

要啟用分片分配，請更新Cluster Update Settings API：

curl -X PUT "localhost:9200/_cluster/settings?pretty" -H 'Content-Type: application/json' -d' {"transient" : {"cluster.routing.allocation.enable" : "all"} } '

如果這解決了問題，您的Kopf或Datadog 儀表板應顯示未分配分片的數量隨著它們成功分配給節點而減少。

未分配的分片數據狗此 Datadog 時間序列圖顯示重新啟用分片分配后未分配的分片數量減少。
啟用分配后未分配的分片更新后的 Kopf 儀表板顯示，在重新啟用分片分配后，許多以前未分配的分片已被分配。
看起來這解決了我們所有未分配分片的問題，只有一個例外：constant-updates索引的分片 0 。讓我們探討分片仍未分配的其他可能原因。

使用 Datadog 查明并解決未分配的分片和其他 Elasticsearch 問題。

原因4：分片數據不再存在于集群中

在這種情況下，constant-updates索引的主分片 0未分配。它可能是在沒有任何副本的節點上創建的（一種用于加速初始索引過程的技術），并且該節點在數據可以復制之前離開了集群。主節點在其全局集群狀態文件中檢測到分片，但無法在集群中定位分片的數據。

另一種可能性是節點在重新啟動時可能遇到了問題。通常，當節點恢復與集群的連接時，它會將有關其磁盤分片的信息中繼到主節點，然后主節點將這些分片從“未分配”轉換為“已分配/已啟動”。當這個過程由于某種原因失敗時（例如節點的存儲以某種方式損壞），分片可能保持未分配狀態。

在這種情況下，您必須決定如何繼續：嘗試讓原始節點恢復并重新加入集群（并執行 不是強制分配主分片），或使用Cluster Reroute API強制分配分片并使用原始數據源或備份重新索引丟失的數據。

如果您決定使用后者（強制分配主分片），需要注意的是您將分配一個“空”分片。如果包含原始主分片數據的節點稍后重新加入集群，則其數據將被新創建的（空）主分片覆蓋，因為它將被視為數據的“較新”版本。在繼續此操作之前，您可能希望重試分配，這將允許您保留存儲在該分片上的數據。

如果您了解其中的含義并且仍想強制分配未分配的主分片，則可以使用該allocate_empty_primary標志來實現。以下命令將constant-updates索引中的主分片 0 重新路由到特定節點：

curl -XPOST "localhost:9200/_cluster/reroute?pretty" -H 'Content-Type: application/json' -d' {"commands" : [{"allocate_empty_primary" : {"index" : "constant-updates", "shard" : 0,"node" : "<NODE_NAME>", "accept_data_loss" : "true"}}] } '

請注意，您需要指定"accept_data_loss" : "true"以確認您已準備好丟失分片上的數據。如果不包含此參數，您將看到如下錯誤：

{"error" : {"root_cause" : [{"type" : "remote_transport_exception","reason" : "[NODE_NAME][127.0.0.1:9300][cluster:admin/reroute]"}],"type" : "illegal_argument_exception","reason" : "[allocate_empty_primary] allocating an empty primary for [constant-updates][0] can result in data loss. Please confirm by setting the accept_data_loss parameter to true"},"status" : 400 }

您現在需要重新索引丟失的數據，或使用Snapshot and Restore API從備份快照中盡可能多地恢復。

原因5：低磁盤水印

如果沒有足夠的節點和足夠的磁盤空間，主節點可能無法分配分片（它不會為使用超過 85% 的磁盤的節點分配分片）。一旦一個節點達到這個磁盤使用水平，或者 Elasticsearch 稱之為“低磁盤水印”，它就不會被分配更多的分片。

您可以通過查詢cat API來檢查集群中每個節點上的磁盤空間（并查看每個節點上存儲了哪些分片）：

curl -s ‘localhost:9200/_cat/allocation?v’
如果任何特定節點的磁盤空間不足（刪除過時的數據并將其存儲在集群外、添加更多節點、升級硬件等），請參閱本文以了解有關如何操作的選項。

如果您的節點具有較大的磁盤容量，則默認的低水位線（85% 的磁盤使用率）可能太低。您可以使用集群更新設置 API來更改cluster.routing.allocation.disk.watermark.low和/或cluster.routing.allocation.disk.watermark.high. 例如，這個Stack Overflow 線程指出，如果你的節點有 5TB 的磁盤容量，你可能可以安全地增加低盤水印 到 90%：

curl -XPUT "localhost:9200/_cluster/settings" -H 'Content-Type: application/json' -d' {"transient": {"cluster.routing.allocation.disk.watermark.low": "90%"} }'

如果您希望您的配置更改在集群重新啟動時保持不變，請將“transient”替換為“persistent”，或者在您的配置文件中更新這些值。您可以選擇使用字節或百分比值來更新這些設置，但一定要記住Elasticsearch 文檔中的這一重要說明：“百分比值是指用過的 磁盤空間，而字節值是指 自由 磁盤空間。”

原因 6：多個 Elasticsearch 版本
這個問題只出現在運行多個版本的 Elasticsearch 的集群中（可能在滾動升級的過程中）。根據Elasticsearch 文檔，主節點不會將主分片的副本分配給任何運行舊版本的節點。例如，如果主分片在 1.4 版本上運行，則主節點將無法將該分片的副本分配給運行 1.4 之前任何版本的任何節點。

如果您嘗試手動將分片從較新版本節點重新路由到較舊版本節點，您將看到如下錯誤：

[NO(target node version [XXX] is older than source node version [XXX])]
Elasticsearch不支持回滾到以前的版本，只支持升級。如果這確實是手頭的問題，升級運行舊版本的節點應該可以解決問題。

你試過把它關掉再打開嗎？
如果上述情況都不適用于您的情況，您仍然可以選擇從原始數據源重新索引丟失的數據，或從舊快照恢復受影響的索引，如此處所述。

總結

以上是生活随笔為你收集整理的如何解决 Elasticsearch 中未分配的分片的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。