01

前言

大家先看兩個故障，帶著問題去思考：

【故障診斷 - 案例 A】首先大致看一下分片未分配原因：

結果顯示分片大都是因為 node_left 導致未分配，然后通過 explain API 查看分片 myindex[3] 不自動分配的具體原因：

我們在 explain api 中指定了只顯示 分片 myindex[3] 的信息，診斷結果的主要信息如下：

意味著 Elasticsearch 找到了這個分片在磁盤的數據，但是由于分片數據不是最新的，無法將其分配為主分片。

【故障診斷 - 案例 B】分片分配失敗，查看日志有如下報錯：

產生該錯誤的原因是副分片與主分片 sync_id 相同，但是 doc 數量不一樣，導致 recovery 失敗。造成 sync_id 相同，但 doc 數量不同的原因可能有多種，例如下面的情況：

1. 寫入過程使用自動生成 docid

2. 主分片寫 doc 完成，轉發請求到副分片

3. 在此期間，并行的一條 delete by query 刪除了主分片上剛剛寫完的 doc，同時副分片也執行了這個刪除請求

4. 主分片轉發的索引請求到達副分片，由于是自動生成 id 的，副分片將直接寫入該 doc，不做檢查。最終導致副分片與主分片 doc 數量不一致。

A、B 兩個案例的解決方式如何？別急，我們先梳理一下 RED 與 YELLOW 問題

02

正文：RED 與 YELLOW

集群 RED 和 YELLOW 是 Elasticsearch 集群最常見的問題之一，無論 RED 還是 YELLOW，原因只有一個：有部分分片沒有分配。

如果有一個以上的主分片沒有被分配，集群以及相關索引被標記為 RED 狀態，如果所有主分片都已成功分配，有部分副分片沒有被分配，集群以及相關索引被標記為 YELLOW 狀態。

對于集群 RED 或 YELLOW 的問題診斷推薦使用 Cluster Allocation Explain API，該 API 可以給出造成分片未分配的具體原因。例如，如下請求可以返回第一個未分配的分片的具體原因：

也可以只查看特定分片未分配的原因：

引用一個官網的例子，API 的返回信息如下：

在返回結果中給出了導致分片未分配的詳細信息，reason 給出了分片最初未分配的原因，可以理解成 unassigned 是什么操作觸發的；

allocate_explanation 則進一步的說明，該分片無法被分配到任何節點，而無法分配的具體原因在 deciders 的 explanation 信息中詳細描述。這些信息足夠我們診斷問題。

分片沒有被分配的最初原因有下列類型：

1. INDEX_CREATED

由于 create index api 創建索引導致，索引創建過程中，把索引的全部分片分配完畢需要一個過程，在全部分片分配完畢之前，該索引會處于短暫的 RED 或 YELLOW 狀態。因此監控系統如果發現集群 RED，不一定代表出現了故障。

2. CLUSTER_RECOVERED

集群完全重啟時，所有分片都被標記為未分配狀態，因此在集群完全重啟時的啟動階段，reason屬于此種類型。

3. INDEX_REOPENED

open 一個之前 close 的索引， reopen 操作會將索引分配重新分配。

4. DANGLING_INDEX_IMPORTED

正在導入一個 dangling index，什么是 dangling index？

磁盤中存在，而集群狀態中不存在的索引稱為 dangling index，例如從別的集群拷貝了一個索引的數據目錄到當前集群，Elasticsearch 會將這個索引加載到集群中，因此會涉及到為 dangling index 分配分片的過程。

5. NEW_INDEX_RESTORED

從快照恢復到一個新索引。

6. EXISTING_INDEX_RESTORED

從快照恢復到一個關閉狀態的索引。

7. REPLICA_ADDED

增加分片副本。

8. ALLOCATION_FAILED

由于分配失敗導致。

9. NODE_LEFT

由于節點離線。

10. REROUTE_CANCELLED

由于顯式的cancel reroute命令。

11. REINITIALIZED

由于分片從 started 狀態轉換到 initializing 狀態。

12. REALLOCATED_REPLICA

由于遷移分片副本。

13. PRIMARY_FAILED

初始化副分片時，主分片失效。

14. FORCED_EMPTY_PRIMARY

強制分配一個空的主分片。

15. MANUAL_ALLOCATION

手工強制分配分片。

03

解決方式

對于不同原因導致的未分配要采取對應的處理措施，因此需要具體問題具體分析。需要注意的是每個索引也有 GREEN，YELLOW，RED 狀態，只有全部索引都 GREEN 時集群才 GREEN，只要有一個索引 RED 或 YELLOW，集群就會處于 RED 或 YELLOW。

如果是一些測試索引導致的 RED，你直接簡單地刪除這個索引。

因此單個的未分配分片就會導致集群 RED 或 YELLOW，一些常見的未分配原因如下：

• 由于配置問題導致的，需要修正相應的配置；
• 由于節點離線導致的，需要重啟離線的節點；
• 由于分片規則限制的，例如 total_shards_per_node，或磁盤剩余空間限制等，需要調整相應的規則；

分配主分片時，由于找不到最新的分片數據，導致主分片未分配，這種要觀察是否有節點離線，極端情況下只能手工分片陳舊的分片為主分片，這會導致丟失一些新入庫的數據。

集群 RED 或 YELLOW 時，一般我們首先需要看一下是否有節點離線，對于節點無法啟動或無法加入集群的問題我們單獨討論。下面我們分享一些 RED 與 YELLOW 的案例及相應的處理方式。

原創：GitChat App Java3y

總結

以上是生活随笔為你收集整理的导致集群重启_解析 Elasticsearch 棘手问题，集群的 RED 与 YELLOW的全部內容，希望文章能夠幫你解決所遇到的問題。

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