聊一聊Elasticsearch的健康狀態
開啟微信掃一掃，關注微信公眾號【資料與演算法聯盟】
轉載請註明出處：http://blog.csdn.net/gamer_gyt
博主微博：http://weibo.com/234654758
Github：https://github.com/thinkgamer
前言
其實一直以來都沒有太關注elsticsearch的健康狀態，只是單純的部署完成，然後es能正常工作就OK了，然而事實卻並非如此，elasticsearch得索引狀態和叢集狀態得不同傳達著不同得意思，下面我們就來看看
叢集狀態
Rest API：
root@c2dbf1f9da5d:/# curl 'http://localhost:9200/_cat/health?v' 我當前得elasticsearch時單機版得，由於載入得索引資料比較多索引顯示為yellow，正常情況下，叢集得健康狀態分為三種：
- green
最健康得狀態，說明所有的分片包括備份都可用 - yellow
基本的分片可用，但是備份不可用（或者是沒有備份） - red
部分的分片可用，表明分片有一部分損壞。此時執行查詢部分資料仍然可以查到，遇到這種情況，還是趕快解決比較好
從上邊檢視的叢集狀態中還包括一些其他資訊：
叢集名字時elasticsearch，叢集的節點個數為1，分片數量為930，活動分片百分比為 50%
檢視各個索引狀態
Rest API：
root@c2dbf1f9da5d:/# curl -k -u admin:admin 'https://localhost:9200/_cat/indices' | grep raoxing-* 我這裡過濾了raoxing-*的索引資料，可以看到raoxing-* 的健康狀態全部為yellow，所以我的叢集（單機版稱為空叢集）的健康狀態也為yellow
索引的健康狀態也有三種，yellow、green、red與叢集的健康狀態解釋是一樣的
狀態為yellow的解決辦法
分片與副本分片
分片用於Elasticsearch在你的叢集中分配資料。想象把分片當作資料的容器。文件儲存在分片中，然後分片分配給你叢集中的節點上。
當你的叢集擴容或縮小，Elasticsearch將會自動在你的節點間遷移分片，以使叢集保持平衡。
一個分片(shard)是一個最小級別的“工作單元(worker unit)”,它只是儲存索引中所有資料的一小片.我們的文件儲存和被索引在分片中，但是我們的程式不知道如何直接與它們通訊。取而代之的是，他們直接與索引通訊.Elasticsearch中的分片分為主分片和副本分片,複製分片只是主分片的一個副本，它用於提供資料的冗餘副本，在硬體故障之後提供資料保護，同時服務於像搜尋和檢索等只讀請求，主分片的數量和複製分片的數量都可以通過配置檔案配置。但是主切片的數量只能在建立索引時定義且不能修改.相同的分片不會放在同一個節點上。
分片演算法
shard = hash(routing) % number_of_primary_shards
routing值是一個任意字串，它預設是_id但也可以自定義，這個routing字串通過雜湊函式生成一個數字，然後除以主切片的數量得到一個餘數(remainder)，餘數的範圍永遠是0到number_of_primary_shards - 1，這個數字就是特定文件所在的分片。
這也解釋了為什麼主切片的數量只能在建立索引時定義且不能修改：如果主切片的數量在未來改變了，所有先前的路由值就失效了，文件也就永遠找不到了。
所有的文件API（get、index、delete、bulk、update、mget）都接收一個routing引數，它用來自定義文件到分片的對映。自定義路由值可以確保所有相關文件.比如使用者的文章,按照使用者賬號路由,就可以實現屬於同一使用者的文件被儲存在同一分片上。
分片與副本互動
新建、索引和刪除請求都是寫(write)操作，它們必須在主分片上成功完成才能複製到相關的複製分片上,下面我們羅列在主分片和複製分片上成功新建、索引或刪除一個文件必要的順序步驟：
1、客戶端給Node 1傳送新建、索引或刪除請求。
2、節點使用文件的_id確定文件屬於分片0。它轉發請求到Node 3，分片0位於這個節點上。
3、Node 3在主分片上執行請求，如果成功，它轉發請求到相應的位於Node 1和Node 2的複製節點上。當所有的複製節點報告成功，Node 3報告成功到請求的節點，請求的節點再報告給客戶端。
客戶端接收到成功響應的時候，文件的修改已經被應用於主分片和所有的複製分片。你的修改生效了
檢視分片狀態
root@c2dbf1f9da5d:/# curl -X GET 'http://localhost:9200/_cluster/health?pretty'
{
"cluster_name" : "elasticsearch",
"status" : "yellow",
"timed_out" : false,
"number_of_nodes" : 1,
"number_of_data_nodes" : 1,
"active_primary_shards" : 931,
"active_shards" : 931,
"relocating_shards" : 0,
"initializing_shards" : 0,
"unassigned_shards" : 930,
"delayed_unassigned_shards" : 0,
"number_of_pending_tasks" : 0,
"number_of_in_flight_fetch" : 0,
"task_max_waiting_in_queue_millis" : 0,
"active_shards_percent_as_number" : 50.02686727565825
}這裡解釋一下為什麼叢集狀態為yellow
由於我們是單節點部署elasticsearch，而預設的分片副本數目配置為1，而相同的分片不能在一個節點上，所以就存在副本分片指定不明確的問題，所以顯示為yellow，我們可以通過在elasticsearch叢集上新增一個節點來解決問題，如果你不想這麼做，你可以刪除那些指定不明確的副本分片（當然這不是一個好辦法）但是作為測試和解決辦法還是可以嘗試的，下面我們試一下刪除副本分片的辦法
解決辦法
root@c2dbf1f9da5d:/# curl -XPUT "http://localhost:9200/_settings" -d' { "number_of_replicas" : 0 } '
{"acknowledged":true}這個時候再次檢視叢集的狀態狀態變成了green
root@c2dbf1f9da5d:/# curl -X GET 'http://localhost:9200/_cluster/health?pretty'
{
"cluster_name" : "elasticsearch",
"status" : "green",
"timed_out" : false,
"number_of_nodes" : 1,
"number_of_data_nodes" : 1,
"active_primary_shards" : 931,
"active_shards" : 931,
"relocating_shards" : 0,
"initializing_shards" : 0,
"unassigned_shards" : 0,
"delayed_unassigned_shards" : 0,
"number_of_pending_tasks" : 0,
"number_of_in_flight_fetch" : 0,
"task_max_waiting_in_queue_millis" : 0,
"active_shards_percent_as_number" : 100.0
}
elasticsearch叢集的一些概念
叢集與節點
節點(node)是你執行的Elasticsearch例項。一個叢集(cluster)是一組具有相同cluster.name的節點集合，他們協同工作，共享資料並提供故障轉移和擴充套件功能，當有新的節點加入或者刪除節點，叢集就會感知到並平衡資料。叢集中一個節點會被選舉為主節點(master),它用來管理叢集中的一些變更，例如新建或刪除索引、增加或移除節點等;當然一個節點也可以組成一個叢集。
節點通訊
我們能夠與叢集中的任何節點通訊，包括主節點。任何一個節點互相知道文件存在於哪個節點上，它們可以轉發請求到我們需要資料所在的節點上。我們通訊的節點負責收集各節點返回的資料，最後一起返回給客戶端。這一切都由Elasticsearch透明的管理。
叢集生態
1.同叢集中節點之間可以擴容縮容,
2.主分片的數量會在其索引建立完成後修正，但是副本分片的數量會隨時變化。
3.相同的分片不會放在同一個節點上.
索引的unssigned問題
這裡的unssigned就是未分配副本分片的問題，在我們執行刪除副本分片是這個問題就沒了
root@c2dbf1f9da5d:/# curl -XPUT "http://localhost:9200/_settings" -d' { "number_of_replicas" : 0 } '
{"acknowledged":true}