最近在處理商品SKU通過ES和MySQL查詢結果不匹配的時候，留意到在elasticsearch中cluster health是yellow,仔細看了一下，elasticsearch的索引狀態和集群狀態的不同傳達着不同得意思。查閱了文檔和一些文章，對ES的集群狀態有了新的認識。無論集群是單節點還是有上百個數據節點，elasticsearch都提供了API接口來查看集群的健康狀態，這樣可以提醒我們處理集群中某處的問題
集群的相關狀態
- green: 所有主要和副本碎片均已分配。您的集群可以100％運行。
- yellow: 所有主分片均已分配，但至少缺少一個副本。沒有數據丟失，因此搜索結果仍將是完整的。但是，您的高可用性在一定程度上受到了損害。如果更多碎片消失，則可能會丟失數據。可以將其yellow視為應該立即進行調查的警告。
- red: 至少缺少一個主分片（及其所有副本）。這意味着您缺少數據：搜索將返回部分結果，而對該分片建立索引將返回異常。
分片和副本的概念及區別
當有大量的文檔時，由於內存的限制、磁盤處理能力不足、無法足夠快的響應客戶端的請求等，一個節點可能不夠。這種情況下，數據可以分為較小的分片。每個分片放到不同的服務器上。當查詢的索引分布在多個分片上時，ES會把查詢發送給每個相關的分片，並將結果組合在一起，而應用程序並不知道分片的存在。即：這個過程對用戶來說是透明的。
為提高查詢吞吐量或實現高可用性，可以使用分片副本。副本是一個分片的精確復制，每個分片可以有零個或多個副本。ES中可以有許多相同的分片，其中之一被選擇更改索引操作，這種特殊的分片稱為主分片。當主分片丟失時，如：該分片所在的數據不可用時，集群將副本提升為新的主分片。
- 分片與副本的區別在於：當分片設置為5，數據量為30G時，es會自動幫我們把數據均衡地分配到5個分片上，即每個分片大概有6G數據，當你查詢數據時，ES會把查詢發送給每個相關的分片，並將結果組合在一起。而副本，就是對分布在5個分片的數據進行復制。因為分片是把數據進行分割而已，數據依然只有一份，這樣的目的是保障查詢的高效性，副本則是多復制幾份分片的數據，這樣的目的是保障數據的高可靠性，防止數據丟失。
elasticsearch集群黃色的原因排查及解決方案
-
部署了單節點集群
由於只有一個節點，而elasticsearch采用默認配置（5分片，1副本），因此群集無法放置副本會處於黃色狀態。
解決方案如下:
可以將副本計數降低到0或將第二個節點添加到群集，以便可以將主分片和副本分片安全地放在不同的節點上。這樣做以后，如果您的節點崩潰，群集中的另一個節點將擁有該分片的副本。 -
elasticsearch分配分片錯誤
進一步可能的原因：已經為集群中的節點數過分分配了副本分片的數量，則分片將保持UNASSIGNED狀態。其錯誤碼為：ALLOCATION_FAILED。
解決方案如下：
reroute：重新路由命令允許手動更改群集中各個分片的分配。 -
磁盤使用過載
磁盤使用超過設定百分比85%。
cluster.routing.allocation.disk.watermark.low——控制磁盤使用的低水位線。 它默認為85％，這意味着Elasticsearch不會將分片分配給使用磁盤超過85％的節點。 它也可以設置為絕對字節值（如500mb），以防止Elasticsearch在小於指定的可用空間量時分配分片。
解決方案：
（1）查看磁盤空間是否超過85%。
（2）刪除不必要的索引，以釋放更多的空間 -
磁盤路徑權限問題
磁盤路徑權限問題。安全起見，默認Elasticsearch非root賬戶和啟動。相關的Elasticsearch數據路徑也是非root權限。
解決方案：
去數據存儲路徑排查權限，或者在data的最外層設置：chown -R elasticsearch:elasticsearch data
elasticsearch 健康狀態API
- 集群狀態查看
curl -XGET 'http://localhost:9200/_cluster/health?pretty=true' - 分片狀態查看
curl -XGET 'http://localhost:9200/_cat/shards?v' - 查看unsigned 的原因
curl -XGET 'http://localhost:9200//_cluster/allocation/explain' - 查看集群中不同節點、不同索引的狀態
curl -XGET 'http://localhost:9200/_cat/shards?h=index,shard,prirep,state,unassigned.reason'