《從0開始學Elasticsearch》—叢集健康和索引管理
內容目錄
1.搭建Kibana
正如《Kibana 使用者手冊》中所介紹，Kibana 是一款開源的資料分析和視覺化平臺，因此我們可以藉助 Kibana 來與Elasticsearch（簡稱ES） 互動。
下載並解壓：
cd /usr/local wget https://artifacts.elastic.co/downloads/kibana/kibana-6.6.1-linux-x86_64.tar.gz tar -zxvf kibana-6.6.1-linux-x86_64.tar.gz -C .
啟動Kibana：
cd kibana-6.6.1-linux-x86_64/ bin/kibana
Kibana 所指向ES的地址預設為localhost，該配置在 config/kibana.yml ，若需要修改，可修改該配置檔案。
Kibana 啟動成功，我們便可以在 Dev Tools選單下的Console中寫 ES命令了，Kibana 的其他功能我們以後再做介紹。
2.叢集健康
在進行索引操作之前，我們有必要先了解一下 ES叢集的健康情況，這將有助於我們看懂索引操作的命令執行之後的執行結果。
檢視叢集的健康情況：
GET _cluster/health
結果：
{
"cluster_name" : "elasticsearch",
"status" : "green",
"timed_out" : false,
"number_of_nodes" : 1,
"number_of_data_nodes" : 1,
"active_primary_shards" : 1,
"active_shards" : 1,
"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
}
從結果中我們可以看出當前叢集的健康情況為 green，active_shards_percent_as_number 為 100.0，兩者什麼意思呢，有沒有必然的聯絡呢？答案當然是有的。
正常情況下，叢集的健康狀態分為green、yellow、red三種。
- green：每個Index的primary shard （即shard）和replica shard（即replica）都是active狀態，都已經分配好。叢集100%可用
- yellow：每個Index的primary shard均為active狀態，但至少還有一個replica shard不是active狀態。此時資料沒有丟失，叢集仍然可用
- red：至少一個primary shard不是active狀態，它的全部replica shard也已缺失。此時資料已經發生了丟失，搜尋時只會返回部分的資料
當叢集狀態非green時，我們可以使用 GET _cluster/health?level=indices 命令檢視各個Index的細節，進而定位具體哪一個索引出現了問題，以便解決問題。
輸出中的relocating_shards為0表明當前沒有分片正在從一個節點遷移至其他節點。為什麼會出現分片遷移這種情況呢？因為ES是一個分散式搜尋分析引擎，而分散式往往對應著海量資料，ES實現了shard負載均衡的功能，當新增新節點或者下線已有節點時，ES的叢集發現機制會自動將shard進行均勻分配（由ES中的 decider 決定，它們是ES中作出分配決定的最高指揮，當使用多個decider 時，若其中一個decider通過投票不贊成重新分配一個分片，那該分片就不能移動了），以保證各個節點上的shard 數幾乎相等，可以均衡的處理各種請求。所以一般情況下relocating_shards的值均為0。
那麼什麼情況下會出現initializing_shards不為0的情況呢？節點剛剛重啟時、剛剛建立分片時等。
unassigned_shards又是一個什麼狀態呢？就是分片已經在叢集狀態中，但是在實際叢集中你又找不到這個分片。例如：兩個節點，一共有2個primary shard，每個primary shard又有兩個replica shard，假設節點1中存在primary shard R0、replica shard R1，節點2中存在primary shard R1，replica shard R0，那麼此時就會有2個replica shard未分配，因為replica shard既不能和自己的primary shard在同一個節點，又不能夠和自己的primary shard的其他replica shard在同一個節點上（even_shard分片分配器決定），此時unassigned_shards就為2。一般未分配的分片都是replica shard。
此外，我們也可以藉助ES的cat API檢視叢集的健康情況，不過cat API的輸出結果並不是以json格式返回的，而是以不帶表頭的表格形式返回的，為了方便理解，我們可以通過新增引數v來將表頭也輸出出來。
GET _cat/health?v
結果：
3.索引操作
-
查詢索引：
GET _cat/indices?v
結果：
從結果中我們可以看到索引的健康情況、狀態、索引名稱、uuid、primary shard個數、replica shard個數、document 個數、被標記為deleted的document 的個數，索引大小、primary shard大小。
-
建立索引：
PUT /indexName
在建立索引時可以指定primary shard的個數，也可以指定一個primary shard配置幾個replica shard。若不指定，則預設一個索引 10個shard，其中5個primary shard，5個replica shard，即使是單節點環境也會如此，這種就是典型的over allocation。如果你知道明確的要放入ES 中的資料集，最好在建立索引時指定一下所需的primary shard 個數及其replica shard個數；否則則需要根據節點數來做決定。
舉例：建立索引order，並指定其包含3個primary shard，每個primary shard配置2個replica shard：
PUT /orders
{
"settings": {
"number_of_shards": 3,
"number_of_replicas": 2
}
}
一旦索引建立成功，則primary shard的個數就不能再修改了，replica shard的個數隨時可以修改。因為ES是根據下面的路由演算法來計算得出該document 應該存放在哪個shard 中的，為了保證在搜尋document 時得出與存放時相同的路由值，故一旦索引建立成功，則primary shard的個數不能再修改。
shard = hash(routing) % number_of_primary_shards
當對document 進行增刪改查操作時，預設會帶一個routing 值，這個值預設為document 的_id，當然也可以通過routing引數指定routing的值。
每個document 僅會存在於一個primary shard 及其 replica shard中，不同primary shard 上儲存的document 都是不同的。
當資料量特別大，需要擴容時，我們一般採用水平擴容的方式，即採購更多相同配置的伺服器，而非採用垂直擴容的方式，即增加容量更大、配置更高的伺服器。之所以採用水平擴容，一是成本問題，二是使用更多的伺服器，可以將shard分散到更多的node上，提高了系統的容錯性，每個node上擁有更少的shard，那麼cpu等資源也可以分配更多到shard上，三是易於以後再次擴容。
-
刪除索引：
DELETE /indexName
如果這篇文章對你有幫助或啟發，歡迎關注和轉發，你的關注和轉發是對我最大的支援。
如果你有什麼疑問想要免費vip服務，歡迎掃描下方二維碼，關注即可獲得1v1免費vip服務。