《從0開始學Elasticsearch》—集羣健康和索引管理

內容目錄

1.搭建Kibana2.集羣健康3.索引操做

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服務。