1. 物理設計
- 1.1 節點和分片
- 1.2 主分片和副本分片
- 1.3 集群擴展
- 1.4 分布式索引和搜索
- - 1.4.1 索引檔案時
  - 1.4.2 搜索索引時
2. 向集群中加入節點
- 2.1 單機集群（偽集群）
- 2.2 新增節點上的分片是如何運作
- 2.3 發現其他 ES 節點
- 2.4 選舉主節點
3. 洗掉集群中的節點
- 3.1 停用節點
- 3.2 擴展策略
- - 3.2.1 過度分片
  - 3.2.2 將資料切分為索引和分片
4. 檢查集群的健康狀態
- 4.1 常用
- 4.2 使用_cat API
5. 路由
- 5.1 為什么使用路由
- 5.2 配置路由

1. 物理設計

1.1 節點和分片

Elasticsearch 創建索引時，默認情況下，每個索引由 5 個主要分片組成，而每份主要分片又有一個副本，一共 10 份分片，副本分片對于可靠性和搜索性能很有益處，技術上而言，一份分片是一個目錄中的檔案，Lucene 用這些檔案存盤索引資料，分片也是 Elasticsearch 將資料從一個節點遷移到另一個節點的最小單位，
一個節點是一個 Elasticsearch 的實體，在服務器上啟動 Elasticsearch 之后，你就擁有了一個節點，如果在另一臺服務器上啟動 Elasticsearch, 這就是另一個節點，甚至可以通過啟動多個 Elasticsearch 行程，在同一臺服務器上擁有多個節點，

在這里插入圖片描述

多個節點可以加入同一個集群，在多節點的集群上，同樣的資料可以在多臺服務器上傳播，這有助于性能，因為 Elasticsearch 有了更多的資源；這同樣有助于穩定性，如果每份分片至少有 1 個副本分片，那么任何一個節點都可以宕機，而 Elasticsearch 依然可以進行服務，并回傳所有資料，
對于使用 Elasticsearch 的應用程式，集群中有 1 個還是多個節點都是透明的，默認情況下，可以連接集群中的任一節點并訪問完整的資料集，就好像集群只有單獨的一個節點，
盡管集群對于性能和穩定性都有好處，但它也有缺點：必須確定節點之間能夠足夠快速地通信，并且不會產生腦裂，
一份分片是 Lucene 的索引：一個包含倒排索引的檔案目錄，倒排索引的結構使得 Elasticsearch 在不掃描所有檔案的情況下，就能告訴你哪些檔案包含特定的詞條 (單詞) ，
Elasticsearch 索引被分解為多塊分片，一份分片是一個 Lucene 的索引，所以一個 Elasticsearch 的索引由多個 Lucene 的索引組成，
一個分片是一個 Lucene 索引（一個倒排索引），它默認存盤原始檔案的內容，再加上一些額外的資訊，如詞條字典和詞頻，這些都能幫助到搜索，
詞條字典將每個詞條和包含該詞條的檔案映射起來，搜索的時候，Elastisearch 沒有必要為了某個詞條掃描所有的檔案，而是根據這個字典快速地識別匹配的檔案，
詞頻使得 Elasticsearch 可以快速地獲取某篇檔案中某個詞條出現的次數，這對于計算結果的相關性得分非常重要，例如，如果搜索“denver"，包含多個 “denver” 的檔案通常更為相關，Elasticsearch 將給它們更高的得分，讓它們出現在結果串列的更前面，
ES 中的節點型別：

Master-eligible nodes 與 Master node
每個節點啟動后,默認就是一個 Master eligible 節點，可以通過設定 node.master:false 來改變，Master-eligible 節點可以參加選主流程,成為 Master 節點，每個節點都保存了集群的狀態,但只有 Master 節點才能修改集群的狀態信息，主節點主要負責集群方面的輕量級的動作，比如：創建或洗掉索引，跟蹤集群中的節點，決定分片分配到哪一個節點，在集群再平衡的程序中，如何在節點間移動資料等，
Data Node
可以保存資料的節點,叫做 Data Node，負責保存分片資料，在資料擴展上起到了至關重要的作用，每個節點啟動后,默認就是一個 Data Node 節點，可以通過設定 node.data:false 來改變，
Ingest Node
可以在檔案建立索引之前設定一些 ingest pipeline 的預處理邏輯，來豐富和轉換檔案，每個節點默認啟動就是 Ingest Node，可用通過 node.ingest = false 來禁用，
Coordinating Node
Coordinating Node 負責接收 Client 的請求,將請求分發到合適的節點,最終把結果匯集到一起，每個節點默認都起到了 Coordinating Node 的職責，當然如果把 master、Data、Ingest 全部禁用，那這個節點就僅是 Coordinating Node 節點了，
Machine Learning Node
用于機器學習處理的節點

1.2 主分片和副本分片

分片可以是主分片，也可以是副本分片，其中副本分片是主分片的完整副本，副本分片可以用于搜索，或者是在原有主分片丟失后成為新的主分片，主分片是權威資料，寫程序先寫主分片，成功后再寫副分片，
Elasticsearch 索引由一個或多個主分片以及零個或多個副本分片構成，副本分片可以在運行的時候進行添加和移除，而主分片不可以，
可以在任何時候改變每個分片的副本分片的數量，因為副本分片總是可以被創建和移除，這并不適用于索引劃分為主分片的數量，在創建索引之前，你必須決定主分片的數量，過少的分片將限制可擴展性，但是過多的分片會影響性能，默認設定主分片的數量是 5 份，
索引主分片的設定：

put test1
{
    "settings": {
        "index.number_of_shards": 3,
        "index.codec": "best_compression"
    }
}

索引副本分片的設定:

put test1/_settings
{
    "index.number_of_replicas": 2
}

1.3 集群擴展

最簡單的 Elasticsearch 集群只有一個節點: 一臺機器運行著一個 Elasticsearch 行程，安裝并啟動 Elasticsearch 之后，就已經建立了一個擁有單節點的集群，隨著越來越多的節點被添加到同一個集群中，現有的分片將在所有的節點中自動進行負載均衡，因此，那些分片上的索引和搜索請求都可以從額外增加的節點中獲益，以這種方式進行擴展(在節點中加入更多節點)被稱為水平擴展，此方式增加更多節點，然后請求被分發到這些節點上，作業負載就被分攤了，
水平擴展的另一個替代方案是垂直擴展，這種方式為 Elasticsearch 的節點增加更多硬體資源，可能是為虛擬機分配更多處理器，或是為物理機增加更多的記憶體，盡管垂直擴展幾乎每次都能提升性能，它并非總是可行的或經濟的，

1.4 分布式索引和搜索

多個節點的多個分片上如何進行索引和搜索

在這里插入圖片描述

1.4.1 索引檔案時

默認情況下，當索引一篇檔案的時候，系統首先根據檔案 ID 的散列值選擇一個主分片，并將檔案發送到該主分片，這份主分片可能位于另一個節點，不過對于應用程式這一點是透明的，
默認地，檔案在分片中均勻分布：對于每篇檔案，分片是通過其 ID 字串的散列決定的，每份分片擁有相同的散列范圍，接收新檔案的機會均等，
一旦目標主分片確定，接受請求的節點將檔案轉發到該主分片所在的節點，隨后，索引操作在該主分片的所有副本分片中進行，在所有可用副本分片完成檔案的索引后，索引命令就會成功回傳，
這使得副本分片和主分片之間保持資料的同步，資料同步使得副本分片可以服務于搜索請求，并在原有主分片無法訪問時自動升級為主分片，

1.4.2 搜索索引時

當搜索一個索引時，Elasticsearch 需要在該索引的完整分片集合中進行查找，這些分片可以是主分片，也可以是副本分片，原因是對應的主分片和副本分片通常包含一樣的檔案，Elasticsearch 在索引的主分片和副本分片中進行搜索請求的負載均衡，使得副本分片對于搜索性能和容錯都有所幫助，
在搜索的時候，接受請求的節點將請求轉發到一組包含所有資料的分片， Elasticsearch 使用 round-robin 的輪詢機制選擇可用的分片(主分片或副本分片), 并將搜索請求轉發過去，Elasticsearch 然后從這些分片收集結果，將其聚集為單一的回復，然后將回復回傳給客戶端應用程式，在默認情況下，搜索請求通過 round-robin 輪詢機制選中主分片和副本分片，

2. 向集群中加入節點

2.1 單機集群（偽集群）

創建 Elasticsearch 集群的第一步，是為單個節點加入另一個節點(或多個節點)，組成節點的集群，
沒有加入第二個節點前：http://192.168.42.111:9200/_cluster/state/master_node,nodes?pretty

在這里插入圖片描述

單機版安裝參考Elasticsearch安裝與配置

如何加入第二個節點：
1、解壓縮壓縮包 elasticsearch-7.14.0-linux-x86_64.tar.gz 到另外一個目錄，比如 elasticsearch-2，并且保證這個 es 中不包含任何資料；
2、修改組態檔

#將 cluster.name 改為和第一個節點一樣
cluster.name: my-elk
#給第二個節點配置獨立的名字
node.name: node-2
#network.host 改為本機地址
network.host: 192.168.42.111
#將 discovery.seed_hosts 改為本機地址
discovery.seed_hosts: ["192.168.42.111"]

在這里插入圖片描述

如果第一個節點有插件，則也需要安裝同樣的插件，然后啟動第二個節點即可，
現在有了第二個 Elasticsearch 節點加入了集群,可以再次http://192.168.42.111:9200/_cluster/state/master_node,nodes?pretty

在這里插入圖片描述

2.2 新增節點上的分片是如何運作

向集群增加一個節點前后，索引發生了些什么，在左端，索引的主分片全部分配到節點 Node1，而副本分片分配沒有地方分配，在這種狀態下，集群是黃色的，因為所有的主分片有了安家之處，但是副本分片還沒有，
一旦第二個節點加入，尚未分配的副本分片就會分配到新的節點 Node2，這使得集群變為了綠色的狀態，
當另一個節點加入的時候，Elasticsearch 會自動地嘗試將分片在所有節點上進行均勻分配，
可以看到集群中有2個節點后，所有的索引都顯示green

在這里插入圖片描述

而單機版時，自己創建的索引顯示yellow

在這里插入圖片描述

如果更多的節點加入集群，Elasticsearch 將試圖在所有的節點上均勻地配置分片數量，這樣每個新加入的節點都能夠通過部分資料(以分片的形式)來分擔負載，
將節點加入 Elasticsearch 集群帶來了大量的好處，主要的收益是高可用性和提升的性能，當副本分片是激活狀態時(默認情況下是激活的),如果無法找到主分片, Elasticsearch 會自動地將一個對應的副本分片升級為主分片，這樣，即使失去了索引主分片所在的節點，仍然可以訪問副本分片上的資料，資料分布在多個節點上同樣提升了性能，原因是主分片和副本分片都可以處理搜索和獲取結果的請求，如此擴展還為整體集群增加了更多的記憶體，所以如果過于消耗記憶體的搜索和聚集運行了太長時間或致使集群耗盡了記憶體，那么加入更多的節點總是一個處理更多更復雜操作的便捷方式，

2.3 發現其他 ES 節點

集群的第二個節點是如何發現第一個節點、并自動地加入集群的，或者在集群中有更多的節點的情況下，如何知道？
Elasticsearch 7.0 中引入的新集群協調子系統來處理這些事，采用的是單播機制，這種機制需要已知節點的串列來進行連接，
單播發現( unicast discovery )讓 Elasticsearch 連接一系列的主機，并試圖發現更多關于集群的資訊，使用單播時，我們告訴 Elasticsearch 集群中其他節點的 IP 地址以及(可選的)埠或埠范圍，
在 elasticsearch.yml 中通過 discovery.seed_hosts 配置種子地址串列，這樣每個節點在啟動時發現和加入集群的步驟就是：
1、去連接種子地址串列中的主機，如果發現某一個 Node 是 Master Eligible Node，那么該 Master Eligible Node 會共享它知道的 Master Eligible Node，這些共享的 Master Eligible Node 也會作為種子地址的一部分繼續去試探；
2、直到找到某一個 seed addresss 對應的是 Master Node 為止；
3、如果第二步沒有找到任何滿足條件的 Node，ES 會默認每隔 1 秒后去重新嘗試尋找，默認為 1 秒
4、重復第三步操作直到找到滿足條件為止，也就是直到最終發現集群中的主節點，會發出一個加入請求給主節點
5、獲得整個集群的狀態資訊，
為什么實體需要知道集群狀態資訊？例如，搜索必須被路由到所有正確的分片，以確保搜索結果是準確的，在索引或洗掉某些檔案時，必須更新每個副本，每個客戶端請求都必須從接收它的節點轉發到能夠處理它的節點，每個節點都了解集群的概況，這樣它們就可以執行搜索、索引和其他協調活動，
discovery.seed_hosts 中的節點地址串列，可以包括集群中部分或者全部集群節點，但是建議無論怎樣都應該包含集群中 Master-eligible nodes 節點的部分或者全部，

2.4 選舉主節點

一旦集群中的節點發現了彼此，它們會協商誰將成為主節點，一個集群有一個穩定的主節點是非常重要的，主節點是唯一一個能夠更新集群狀態的節點，主節點一次處理一個集群狀態更新，應用所需的更改并將更新的集群狀態發布到集群中的所有其他節點，
Elasticsearch 認為所有的節點都有資格成為主節點，除非某個節點的 node.master 選項設定為 false，而 node.master 在不做配置的情況下，預設為 true，
如果完全使用默認配置啟動新安裝的 Elasticsearch 節點，它們會自動查找在同一主機上運行的其他節點，并在幾秒鐘內形成集群，在生產環境或其他分布式環境中還不夠健壯，現在還存在一些風險：節點可能無法及時發現彼此，可能會形成兩個或多個獨立的集群，從 Elasticsearch 7.0 開始，如果你想要啟動一個全新的集群，并且集群在多臺主機上都有節點，那么你必須指定該集群在第一次選舉中應該使用的一組符合主節點條件的節點作為選舉配置，這就是所謂的集群引導，也可以稱為集群自舉，只在首次形成集群時才需要，
cluster.initial_master_nodes 這個引數就是用來設定一系列符合主節點條件的節點的主機名或 IP 地址來進行集群自舉，集群形成后，不再需要此設定，并且會忽略它，也就是說，這個屬性就只是在集群首次啟動時有用，
在向集群添加新的符合主節點條件的節點時不再需要任何特殊的儀式，只需配置新節點，讓它們可以發現已有集群，并啟動它們，當有新節點加入時，集群將會自動地調整選舉配置，
在主節點被選舉出來之后，它會建立內部的 ping 機制來確保每個節點在集群中保持活躍和健康，這被稱為錯誤識別( fault detection), 有兩個故障檢測行程在集群的生命周期中一直運行，一個是主節點的，ping 集群中所有的其他節點，檢查他們是否活著，另一種是每個節點都 ping 主節點，確認主節點是否仍在運行或者是否需要重新啟動選舉程式，
在 Elasticsearch7 以前的版本中，為了預防集群產生腦裂( split brain)的問題， Elasticsearch 6.x 及之前的版本使用了一個叫作 Zen Discovery 的集群協調子系統，往往會將 discovery.zen.minimum_master_nodes 設定為集群節點數除以 2 再加上 1，例如，3 個節點的集群 discovery.zen.minimum_master_nodes 要設定為 2，而對于 14 個節點的集群，最好將其設定為 8，
在 Elasticsearch 7 以后里重新設計并重建了的集群協調子系統，移除 minimum_master_nodes 引數，轉而由集群自主控制，
什么是 Elasticsearch 的腦裂？
腦裂這個詞描述了這樣的場景:(通常是在重負荷或網路存在問題的情況下)Elasticsearch 集群中一個或多個節點失去了和主節點的通信，開始選舉新的主節點，并且繼續處理請求，這個時候，可能有兩個不同的 Elasticsearch 集群相互獨立地運行著，這就是“腦裂”一詞的由來，因為單一的集群已經分裂成了兩個不同的部分，和左右大腦類似，為了防止這種情況的發生，Elasticsearch 7 以前版本你需要根據集群節點的數量來設定 discovery. zen.minimum_master_nodes，如果節點的數量不變，將其設定為集群節點的總數；否則將節點數除以 2 并加 1 是一個不錯的選擇，因為這就意味著如果一個或多個節點失去了和其他節點的通信，它們無法選舉新的主節點來形成新集群，因為對于它們不能獲得所需的節點(可成為主節點的節點)數量(超過一半)，

3. 洗掉集群中的節點

假設節點 1 宕機了，那么在節點 1 的 3 個分片怎么辦?

在這里插入圖片描述

Elasticsearch 所做的第 1 件事情是自動地將節點 2 上的 0 和 3 副本分片轉為主分片，這是由于索引操作會首先更新主分片，所以 Elasticsearch 要盡力使索引的主分片正常運作，Elasticsearch 可以選擇任一個副本分片并將其轉變為主分片，只是在本例中每個主分片僅有一個副本分片供選擇，就是節點 Node2 上的副本分片，

在這里插入圖片描述

副本分片變為主分片之后，集群就會變為黃色的狀態，這意味著某些副本分片尚未分配到某個節點，Elasticsearch 下一步需要創建更多的副本分片來保持索引的高可用性，由于所有的主分片現在都是可用的，節點 2 上 0 和 3 主分片的資料會復制到節點 3 上作為副本分片，而節點 3 上 1 主分片的資料會復制到節點 2，

在這里插入圖片描述

一旦副本分片被重新創建，并用于彌補損失的節點，那么集群將重新回歸綠色的狀態，全部的主分片及其副本分片都分配到了某個節點，在這個時間段內，整個集群都是可用于搜索和索引的，因為實際上沒有丟失資料，
如果失去的節點多于 1 個，或者某個沒有副本的主分片丟失了，那么集群就會變為紅色的狀態，這意味著某些資料永遠地丟失了，你需要讓集群重連擁有丟失資料的節點，或者對丟失的資料重新建立索引，
就副本分片的數量而言，你需要理解自己愿意承擔多少風險，這一點非常重要，有 1 份副本分片意味著集群可以缺失 1 個節點而不丟失資料，如果有 2 個副本分片，可以缺失 2 個節點而不丟失資料，以此類推，所以，確保你選擇了合適的副本數量來備份你的索引，

3.1 停用節點

當節點宕機時，讓 Elasticsearch 自動地創建新副本分片是個很好的選擇，可是，當集群進行例行維護的時候，如果希望關閉某個包含資料的節點，而同時不讓集群進人黃色的狀態，可以通過殺掉 Java 行程來停止節點，然后讓 Elasticsearch 將資料恢復到其他節點，但是如果你的索引沒有副本分片的時候怎么辦?這意味著，如果不預先將資料轉移，關閉節點就會讓你丟失資料!
Elasticsearch 有一種停用節點( decommission)的方式，告訴集群不要再分配任何分片到某個或 1 組節點上，在 3 個節點的情況中，假設節點 1、節點 2 和節點 3 的 IP 地址分別是 192.168.1.10、192.168.1.11 和 192.168.1.12，如果你想關閉節點 1 的同時保持集群為綠色狀態，可以先停用節點，這個操作會將待停用節點上的所有分片轉移到集群中的其他節點，系統通過集群設定的臨時修改，來為你實作節點的停用

PUT _cluster/settings
{
    "transient": {
        "cluster.routing.allocation.exclude._name": "node-1"
    }
}

或者

PUT _cluster/settings
{
    "transient": {
        "cluster.routing.allocation.exclude._ip": "192.168.1.10"
    }
}

一旦運行了這個命令，Elaticsearch 將待停用節點上的全部分片開始轉移到集群中的其他節點上，
該程序可以重復，每次停止一個你想關閉的節點，或者也可以使用一個通過逗號分隔的 IP 地址串列，一次停止多個節點，請記住，集群中的其他節點必須有足夠的磁盤和記憶體來處理分片的分配，所以在停止多個節點之前，做出相應的計劃來確保你有足夠的資源，

3.2 擴展策略

Elasticsearch 的使用方式各有各的不同，所以需要根據如何索引和搜索資料，為集群選擇最佳的配置，通常來說，規劃生產環境的 Elasticsearch 集群至少需要考慮：過度分片、將資料切分為索引和分片，

3.2.1 過度分片

過度分片( over-sharding )是指你有意地為索引創建大量分片，用于未來增加節點的程序，假設我們已經創建了擁有單一分片、無副本分片的索引，但是，在增加了另外一個節點之后又會發生什么?
我們將得不到增加集群節點所帶來的任何好處了，由于全部的索引和查詢負載仍然是由擁有單一分片的節點所處理，所以即使增加了一個節點你也無法進行擴展，
因為分片是 Elasticsearch 所能移動的最小單位，所以確保你至少擁有和集群節點一樣多的主分片總是個好主意，如果現在有一個 5 個節點、11 個主分片的集群，那么當你需要加入更多的節點來處理額外的請求時，就有成長的空間，使用同樣的例子，如果你突然需要多于 11 個的節點，就不能在所有的節點中分發主分片，因為節點的數量將會超出分片的數量，
怎么辦？創建一個有 10000 個主分片的索引？一開始的時候，這看上去是個好主意，但是 Elasticsearch 管理每個分片都隱含著額外的開銷，每個分片都是完整的 Lucene 索引，它需要為索引的每個分段創建一些檔案描述符，增加相應的記憶體開銷，如果索引有過多的活躍分片，可能會占用了本來支撐性能的記憶體，或者觸及機器檔案描述符或記憶體的極限，對資料的壓縮也會有影響，
值得注意的是，沒有對所有案例適用的完美分片索引比例，Elasticsearch 選擇的默認設定是 5 個分片，對于普通的用例是不錯的主意，但是考慮你的規劃在將來是如何增長(或縮減)所建分片的數量，這總是很件重要的事情，
一旦包含某些數量分片的索引被創建，其主分片的數量永遠是不能改變的，
Elasticsearch 索引能處理多大的資料：
單一索引的極限取決于存盤索引的機器之型別、你準備如何處理資料以及索引備份了多少副本，
如何評估 ES 中的資料量是否合適呢？有幾個參考值
1、ES 官方推薦分片的大小是 20G - 40G，最大不能超過 50G，
2、每個節點上可以存盤的分片數量與可用的堆記憶體大小成正比關系，但是 Elasticsearch 并未強制規定固定限值，這里有一個很好的經驗法則：確保對于節點上已配置的每個 GB，將分片數量保持在 20 以下，如果某個節點擁有 3GB 的堆記憶體，那最多可有 60 個分片，那么有三個機器的集群，ES 可用總堆記憶體是 9GB，則最多是 180 個分片，注意這個資料是包含了主副分片的，但是在此限值范圍內，設定的分片數量越少，效果就越好，
3、通常來說，一個 Lucene 索引(也就是一個 Elasticsearch 分片)不能處理多于 21 億篇檔案，或者多于 2740 億的唯一詞條，但是在達到這個極限之前，你可能就已經沒有足夠的磁盤空間了，
舉例：三個機器的集群，總記憶體是 9GB，準備 1 主 2 副，支持的總主分片數量最大不宜超過 60 個分片，

3.2.2 將資料切分為索引和分片

現在還沒有方法讓我們增加或者減少某個索引中的主分片數量,但是你總是可以對資料進行規劃，讓其橫跨多個索引，這是另一種完全合理的切分資料的方式，
比如說以地理位置創建索引和分片，你可以為西藏索引創建 2 個主分片，而為上海索引創建 10 個主分片，或者可以將資料以日期來分段，為資料按年份創建索引: 2020、 2021 和 2022 等，以這種方式將資料分段，對于搜索同樣有所幫助，因為分段將恰當的資料放在恰當的位置，如果顧客只希望搜索 2021 年和 2022 年的活動或分組，你只需要搜索相應的索引，而不是整個資料集中檢索，
使用索引進行規劃的另一種方式是別名，別名( alias )就像指向某個索引或一組索引的指標，別名也允許你隨時修改其所指向的索引，對于資料按照語意的方式來切分，這一點非常有用，你可以創建一個別名稱為去年，指向 2021，當 2023 年 1 月 1 日到來，就可以將這個別名指向 2022 年的索引，
當索引基于日期的資訊時(就像日志檔案)，這項技術是很常用的，如此一來資料就可以按照每月、每周、每日等日期來分段，而每次分段過時的時候，“當前”的別名永遠可用來指向應該被搜索的資料，而無須修改待搜索的索引之名稱，此外，別名擁有驚人的靈活性，而且幾乎沒有額外負載，所以值得嘗試，

4. 檢查集群的健康狀態

4.1 常用

集群的健康 API 介面提供了一個方便但略有粗糙的概覽，包括集群、索引和分片的整體健康狀況，這通常是發現和診斷集群中常見問題的第一步，
http://192.168.42.111:9200/_cluster/health?pretty 從這個答復的表明資訊，我們可以推斷出很多關于集群整體健康狀態的資訊，

在這里插入圖片描述

“cluster_name” : 集群名稱
“status” :正常情況下，Elasticsearch 集群健康狀態分為三種：
green 最健康得狀態，說明所有的分片包括備份都可用; 這種情況 Elasticsearch 集群所有的主分片和副本分片都已分配, Elasticsearch 集群是 100% 可用的，
yellow 基本的分片可用，但是備份不可用（或者是沒有備份）; 這種情況 Elasticsearch 集群所有的主分片已經分片了，但至少還有一個副本是缺失的，不會有資料丟失，所以搜索結果依然是完整的，不過，你的高可用性在某種程度上被榷訓，如果更多的分片消失，你就會丟資料了，把 yellow 想象成一個需要及時調查的警告，
red 部分的分片可用，表明分片有一部分損壞，此時執行查詢部分資料仍然可以查到，遇到這種情況，還是趕快解決比較好; 這種情況 Elasticsearch 集群至少一個主分片（以及它的全部副本）都在缺失中，這意味著你在缺少資料：搜索只能回傳部分資料，而分配到這個分片上的寫入請求會回傳一個例外，
“timed_out” : 是否有超時
“number_of_nodes” : 集群中的節點數量
“number_of_data_nodes” : 資料節點數
“active_primary_shards” : 指出你集群中的主分片數量
“active_shards” : 所有索引的_所有_分片的匯總值，即包括副本分片
“relocating_shards” : 大于 0 表示 Elasticsearch 正在集群內移動資料的分片,來提升負載均衡和故障轉移，這通常發生在添加新節點、重啟失效的節點或者洗掉節點的時候，因此出現了這種臨時的現象
“initializing_shards” : 當用戶剛剛創建一個新的索引或者重啟一個節點的時候，這個數值會大于 0
“unassigned_shards” : 這個值大于 0 的最常見原因是有尚未分配的副本分片，在開發環境中，這個問題很普遍，因為單節點的集群其索引默認有 5 個分片和 1 個副本分片，這種情況下，由于無多余節點來分配副本分片，因此還有 5 個未分配的副本分片
“active_shards_percent_as_number” : 集群分片的可用性百分比，如果為 0 則表示不可用
集群健康 API 提供了更多的細粒度的操作，允許用戶進一步地診斷問題，在這個例子中，可以通過添加 level 引數，深入了解哪些索引受到了分片未配置的影響，比如：http://192.168.42.111:9200/_cluster/health?level=indices&pretty=true

在這里插入圖片描述

除此之外與集群相關的 API 還有：
查看集群健康狀態介面(_cluster/health)
查看集群狀況介面(_cluster/state)
查看集群統計資訊介面(_cluster/stats)
查看集群掛起的任務介面(_cluster/pending_tasks)
集群重新路由操作(_cluster/reroute)
更新集群設定(_cluster/settings)
節點狀態(_nodes/stats)
節點資訊(_nodes)
節點的熱執行緒(_nodes/hot_threads)
關閉節點(_nodes/_master/_shutdown)

4.2 使用_cat API

有的時候可讀性很重要，我們就需要更方便的_cat API 介面，這個_cat API 提供了很有幫助的診斷和除錯工具，將資料以更好的可讀性列印出來，
_cat API 有很多特性，它們對于除錯集群的各個方面都是很有幫助的，你可以運行http://192.168.42.111:9200/_cat來查看所支持的_cat API 介面的完整清單，

在這里插入圖片描述
allocation-展示分配到每個節點的分片數量，
count-統計整個集群或索引中檔案的數量，如：GET _cat/count/employees?v
health–展示集群的健康狀態，
indices-展示現有索引的資訊，
master—顯示目前被選為主節點的節點，
nodes—顯示集群中所有節點的不同資訊，
recovery–顯示集群中正在進行的分片恢復狀態，
shards-展示集群中分片的數量、大小和名字，
plugins—展示已安裝插件的資訊，

5. 路由

知道檔案是如何以通過分片形式來定位的，這個程序被稱為路由 ( routing )檔案，
當 Elasticsearch 散列檔案的 ID 時就會發生檔案的路由，來決定檔案應該索引到哪個分片中，這可以由你指定也可以讓 Elasticsearch 生成，
索引的時候，Elasticsearch 也允許你手動地指定檔案的路由，使用父子關系實際上就是這種操作，因為子檔案必須要和父檔案在同一個分片，

5.1 為什么使用路由

假設你有一個 100 個分片的索引，當一個請求在集群上執行時會發生什么？

這個搜索的請求會被發送到一個節點
接收到這個請求的節點，將這個查詢轉到這個索引的每個分片上（可能是主分片，也可能是副本分片）
每個分片執行這個搜索查詢并回傳結果
結果在通道節點上合并、排序并回傳給用戶

因為默認情況下，Elasticsearch 使用檔案的 ID（類似于關系資料庫中的自增 ID），如果插入資料量比較大，檔案會平均的分布于所有的分片上，這導致了 Elasticsearch 不能確定檔案的位置，所以它必須將這個請求轉到所有的 N 個分片上去執行，這種操作會給集群帶來負擔，增大了網路的開銷；那么如何確定請求在哪個分片上執行呢?Elasticsearch 提供了一個 API 介面，告訴我們一個搜索請求在哪些節點和分片上執行，
_search_shards API
比如我們創建一個兩分片的索引：

put open-soft-shard
{
    "settings": {
        "index.number_of_shards": 2
    }
}

在這里插入圖片描述

并放入資料：

put /open-soft-shard/_doc/1
{
    "name": "Apache Hadoop",
    "lang": "Java",
    "corp": "Apache",
    "stars": 200
}

在這里插入圖片描述

多插入幾條

put /open-soft-shard/_doc/2
{
    "name": [
        "Apache Activemq",
        "Activemq Artemis"
    ],
    "lang": "Java",
    "corp": "Apache",
    "stars": [
        500,
        200
    ]
}
put /open-soft-shard/_doc/3
{
    "name": [
        "Apache Kafka"
    ],
    "lang": "Java",
    "corp": "Apache",
    "stars": [
        500,
        400
    ]
}
put /open-soft-shard/_doc/object
{
    "name": [
        "Apache ShardingSphere"
    ],
    "lang": "Java",
    "corp": "JingDong",
    "stars": 400,
    "address": {
        "city": "BeiJing",
        "country": "亦莊"
    }
}

使用搜索分片( search shards ) 的 API 介面來查看請求將在哪些分片上執行，可以看到，會搜索全部的兩個分片，

{
  "nodes" : {
    "hwybgn34TuW2LJrOm_FSog" : {
      "name" : "node-2",
      "ephemeral_id" : "cllkC8AmQVyrBAyyJSNiaA",
      "transport_address" : "192.168.42.111:9301",
      "attributes" : {
        "ml.machine_memory" : "1019797504",
        "ml.max_open_jobs" : "512",
        "xpack.installed" : "true",
        "ml.max_jvm_size" : "1065025536",
        "transform.node" : "true"
      },
      "roles" : [
        "data",
        "data_cold",
        "data_content",
        "data_frozen",
        "data_hot",
        "data_warm",
        "ingest",
        "master",
        "ml",
        "remote_cluster_client",
        "transform"
      ]
    },
    "6Xx-CoJjSquj9kn716ZjnQ" : {
      "name" : "node-1",
      "ephemeral_id" : "F7phlqAlR6iXhPSMcSjEkw",
      "transport_address" : "192.168.42.111:9300",
      "attributes" : {
        "ml.machine_memory" : "1019797504",
        "xpack.installed" : "true",
        "transform.node" : "true",
        "ml.max_open_jobs" : "512",
        "ml.max_jvm_size" : "1065025536"
      },
      "roles" : [
        "data",
        "data_cold",
        "data_content",
        "data_frozen",
        "data_hot",
        "data_warm",
        "ingest",
        "master",
        "ml",
        "remote_cluster_client",
        "transform"
      ]
    }
  },
  "indices" : {
    "open-soft-shard" : { }
  },
  "shards" : [
    [
      {
        "state" : "STARTED",
        "primary" : false,
        "node" : "6Xx-CoJjSquj9kn716ZjnQ",
        "relocating_node" : null,
        "shard" : 0,
        "index" : "open-soft-shard",
        "allocation_id" : {
          "id" : "PFQxVNY4SLGplOqICMXJpQ"
        }
      },
      {
        "state" : "STARTED",
        "primary" : true,
        "node" : "hwybgn34TuW2LJrOm_FSog",
        "relocating_node" : null,
        "shard" : 0,
        "index" : "open-soft-shard",
        "allocation_id" : {
          "id" : "Ucj_fOFATYqUOBlye3nOUA"
        }
      }
    ],
    [
      {
        "state" : "STARTED",
        "primary" : true,
        "node" : "6Xx-CoJjSquj9kn716ZjnQ",
        "relocating_node" : null,
        "shard" : 1,
        "index" : "open-soft-shard",
        "allocation_id" : {
          "id" : "9FsKkjcSQOOiWhKI4CDxuA"
        }
      },
      {
        "state" : "STARTED",
        "primary" : false,
        "node" : "hwybgn34TuW2LJrOm_FSog",
        "relocating_node" : null,
        "shard" : 1,
        "index" : "open-soft-shard",
        "allocation_id" : {
          "id" : "5bznRFT0Sr2beunL_BEbFA"
        }
      }
    ]
  ]
}

當我們

GET /open-soft-shard/_search_shards?pretty&routing=1

即使在索引中只有兩個分片,當指定路由值 1 的時候，只有分片 shard 0 會被搜索，對于搜索需要查找的資料，有效地切除了一半的資料量!

#! Elasticsearch built-in security features are not enabled. Without authentication, your cluster could be accessible to anyone. See https://www.elastic.co/guide/en/elasticsearch/reference/7.14/security-minimal-setup.html to enable security.
{
  "nodes" : {
    "hwybgn34TuW2LJrOm_FSog" : {
      "name" : "node-2",
      "ephemeral_id" : "cllkC8AmQVyrBAyyJSNiaA",
      "transport_address" : "192.168.42.111:9301",
      "attributes" : {
        "ml.machine_memory" : "1019797504",
        "ml.max_open_jobs" : "512",
        "xpack.installed" : "true",
        "ml.max_jvm_size" : "1065025536",
        "transform.node" : "true"
      },
      "roles" : [
        "data",
        "data_cold",
        "data_content",
        "data_frozen",
        "data_hot",
        "data_warm",
        "ingest",
        "master",
        "ml",
        "remote_cluster_client",
        "transform"
      ]
    },
    "6Xx-CoJjSquj9kn716ZjnQ" : {
      "name" : "node-1",
      "ephemeral_id" : "F7phlqAlR6iXhPSMcSjEkw",
      "transport_address" : "192.168.42.111:9300",
      "attributes" : {
        "ml.machine_memory" : "1019797504",
        "xpack.installed" : "true",
        "transform.node" : "true",
        "ml.max_open_jobs" : "512",
        "ml.max_jvm_size" : "1065025536"
      },
      "roles" : [
        "data",
        "data_cold",
        "data_content",
        "data_frozen",
        "data_hot",
        "data_warm",
        "ingest",
        "master",
        "ml",
        "remote_cluster_client",
        "transform"
      ]
    }
  },
  "indices" : {
    "open-soft-shard" : { }
  },
  "shards" : [
    [
      {
        "state" : "STARTED",
        "primary" : false,
        "node" : "6Xx-CoJjSquj9kn716ZjnQ",
        "relocating_node" : null,
        "shard" : 0,
        "index" : "open-soft-shard",
        "allocation_id" : {
          "id" : "PFQxVNY4SLGplOqICMXJpQ"
        }
      },
      {
        "state" : "STARTED",
        "primary" : true,
        "node" : "hwybgn34TuW2LJrOm_FSog",
        "relocating_node" : null,
        "shard" : 0,
        "index" : "open-soft-shard",
        "allocation_id" : {
          "id" : "Ucj_fOFATYqUOBlye3nOUA"
        }
      }
    ]
  ]
}

所以當處理擁有大量分片的索引時，路由會很有價值，當然對于 Elasticsearch 的常規使用它并不是必需的

5.2 配置路由

路由也可以不使用檔案的 ID，而是定制的數值進行散列，通過指定 URL 中的 routing 查詢引數，系統將使用這個值進行散列，而不是 ID，

PUT /employees/_doc/2?routing=rountkey
{
	......
}

在這個例子中，rountkey 這個由我們自己輸入的值決定檔案屬于哪個分片的散列值，而不是檔案的 ID 值 2，
由上可知，自定義路由的方式非常簡單，只需要在插入資料的時候指定路由的 key 即可，雖然使用簡單，但有細節需要注意，

1、先創建一個名為 study_route 的索引，該索引有 2 個 shard，0 個副本

PUT study_route/
{
    "settings": {
        "number_of_shards": 2,
        "number_of_replicas": 0
    }
}

在這里插入圖片描述
2、查看 shard

GET _cat/shards/study_route?v

在這里插入圖片描述
3、插入第 1 條資料

PUT study_route/_doc/a?refresh
{
    "data": "A"
}

在這里插入圖片描述
4、查看 shard

從208b變為3.7kb

GET _cat/shards/study_route?v

在這里插入圖片描述
5、插入第 2 條資料

PUT study_route/_doc/b?refresh
{
    "data": "B"
}

在這里插入圖片描述
6、查看 shard

在這里插入圖片描述
7、查看此時索引里面的資料

GET study_route/_search

在這里插入圖片描述

先創建了一個擁有 2 個 shard，0 個副本（為了方便觀察）的索引 study_route ，創建完之后查看兩個 shard 的資訊，此時 shard 為空，里面沒有任何檔案（docs 列為 0），接著我們插入了兩條資料，每次插完之后，都檢查 shard 的變化，通過對比可以發現 docid=a 的第一條資料寫入了 0 號 shard， docid=b 的第二條資料寫入了 1 號 shard，
接著，我們指定 routing，看看有什么變化，

8、插入第 3 條資料

PUT study_route/_doc/c?routing=key1&refresh
{
    "data": "C"
}

在這里插入圖片描述
9、查看 shard

GET _cat/shards/study_route?v

在這里插入圖片描述
10、查看索引資料

GET study_route/_search

在這里插入圖片描述

又插入了 1 條 docid=c 的新資料，但這次指定了路由，路由的值是一個字串"key1"，通過查看 shard 資訊，能看出這條資料路由到了 0 號 shard，也就是說用"key1"做路由時，檔案會寫入到 0 號 shard，
接著我們使用該路由再插入兩條資料，但這兩條資料的 docid 分別為之前使用過的 “a"和"b”，最終結果會是什么樣？

11、插入 docid=a 的資料，并指定 routing=key1

PUT study_route/_doc/a?routing=key1&refresh
{
    "data": "A with routing key1"
}

在這里插入圖片描述

es 的回傳資訊表明檔案 a 是 updated

12、查看 shard
在這里插入圖片描述

13、查詢索引
在這里插入圖片描述

14、插入 docid=b 的資料，使用 key1 作為路由欄位的值
在這里插入圖片描述

es 回傳的資訊變成了 created

15、查看 shard 資訊
在這里插入圖片描述

16、查詢索引內容
在這里插入圖片描述

兩個 id 為 b 的檔案，其中一個比另一個多了一個欄位"_routing"
和步驟 11 插入 docid=a 的那條資料相比，這次這個有些不同，我們來分析一下，步驟 11 中插入 docid=a 時，es 回傳的是 updated，也就是更新了步驟 2 中插入的 docid 為 a 的資料，步驟 12 和 13 中查詢的結果也能看出，并沒有新增資料，route_test 中還是只有 3 條資料，
而步驟 14 插入 docid=b 的資料時，es 回傳的是 created，也就是新增了一條資料，而不是 updated 原來 docid 為 b 的資料，步驟 15 和 16 的確也能看出多了一條資料，現在有 4 條資料，而且從步驟 16 查詢的結果來看，有兩條 docid 為 b 的資料，但一個有 routing，一個沒有，而且也能分析出有 routing 的在 0 號 shard 上面，沒有的那個在 1 號 shard 上，
這個就是我們自定義 routing 后會導致的一個問題：docid 不再全域唯一，ES shard 的實質是 Lucene 的索引，所以其實每個 shard 都是一個功能完善的倒排索引，ES 能保證 docid 全域唯一是采用 docid 作為了路由，所以同樣的 docid 肯定會路由到同一個 shard 上面，如果出現 docid 重復，就會 update 或者拋例外，從而保證了集群內 docid 唯一標識一個 doc，但如果我們換用其它值做 routing，那這個就保證不了了，如果用戶還需要 docid 的全域唯一性，那只能自己保證了，因為 docid 不再全域唯一，所以 doc 的增刪改查 API 就可能產生問題，比如下面的查詢：

GET study_route/_doc/b

在這里插入圖片描述

GET study_route/_doc/b?routing=key1

在這里插入圖片描述

上面兩個查詢，雖然指定的 docid 都是 b，但回傳的結果是不一樣的，所以，如果自定義了 routing 欄位的話，一般 doc 的增刪改查介面都要加上 routing 引數以保證一致性，
為此，ES 在 mapping 中提供了一個選項，可以強制檢查 doc 的增刪改查介面是否加了 routing 引數，如果沒有加，就會報錯，設定方式如下：

PUT <索引名>
{
    "settings": {
        "number_of_shards": 2,
        "number_of_replicas": 0
    },
    "mappings": {
        "_routing": {
            "required": true//設定為true，則強制檢查；false則不檢查，默認為false
        }
    }
}

比如：

PUT study_route1/
{
    "settings": {
        "number_of_shards": 2,
        "number_of_replicas": 0
    },
    "mappings": {
        "_routing": {
            "required": true
        }
    }
}

在這里插入圖片描述

寫入一條資料

PUT study_route1/_doc/b?routing=key1
{
    "data": "b with routing"
}

在這里插入圖片描述

但是以下的增刪改查都會抱錯

GET study_route1/_doc/b
PUT study_route1/_doc/b
{
    "data": "B"
}
DELETE study_route1/_doc/b

在這里插入圖片描述

很多時候自定義路由是為了減少查詢時掃描 shard 的個數，從而提高查詢效率，默認查詢介面會搜索所有的 shard，但也可以指定 routing 欄位，這樣就只會查詢 routing 計算出來的 shard，提高查詢速度，
使用方式也非常簡單，只需在查詢陳述句上面指定 routing 即可，允許指定多個：
查詢所有磁區 GET study_route/

GET study_route/_search
{
    "query": {
        "match": {
            "data": "B"
        }
    }
}

在這里插入圖片描述

查詢指定磁區

GET study_route/_search?routing=key1
{
    "query": {
        "match": {
            "data": "B"
        }
    }
}

在這里插入圖片描述

轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/438667.html

標籤：其他

上一篇：第5.3章：StarRocks審計日志插件（拓展篇）

下一篇：kafka手動調整磁區副本數

Elasticsearch 集群

目錄

1. 物理設計

1.1 節點和分片

1.2 主分片和副本分片

1.3 集群擴展

1.4 分布式索引和搜索

1.4.1 索引檔案時

1.4.2 搜索索引時

2. 向集群中加入節點

2.1 單機集群（偽集群）

2.2 新增節點上的分片是如何運作

2.3 發現其他 ES 節點

2.4 選舉主節點

3. 洗掉集群中的節點

3.1 停用節點

3.2 擴展策略

3.2.1 過度分片

3.2.2 將資料切分為索引和分片

4. 檢查集群的健康狀態

4.1 常用

4.2 使用_cat API

5. 路由

5.1 為什么使用路由

5.2 配置路由