elasticsearch叢集擴容和容災
elasticsearch專欄：https://www.cnblogs.com/hello-shf/category/1550315.html
一、叢集健康
Elasticsearch 的叢集監控資訊中包含了許多的統計資料，其中最為重要的一項就是叢集健康，它在 status 欄位中展示為 green 、 yellow 或者 red。
在kibana中執行：GET /_cat/health?v
1 epoch timestamp cluster status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent 2 1568794410 08:13:30 my-application yellow 1 1 47 47 0 0 40 0 - 54.0%
其中我們可以看到當前我本地的叢集健康狀態是yellow ，但這裡問題來了，叢集的健康狀況是如何進行判斷的呢？
green（很健康）
所有的主分片和副本分片都正常執行。
yellow（亞健康）
所有的主分片都正常執行，但不是所有的副本分片都正常執行。
red（不健康）
有主分片沒能正常執行。
注意：
我本地只配置了一個單節點的elasticsearch，因為primary shard和replica shard是不能分配到一個節點上的所以，在我本地的elasticsearch中是不存在replica shard的，所以健康狀況為yellow。
二、shard和replica
為了將資料新增到Elasticsearch，我們需要索引(index)——一個儲存關聯資料的地方。實際 上，索引只是一個用來指向一個或多個分片(shards)的“邏輯名稱空間(logical namespace)”. 一個分片(shard)是一個最小級別“工作單元(worker unit)”,它只是儲存了索引中所有資料的一 部分。道分片就是一個Lucene例項，並且它本身就是一個完整的搜尋引擎。我們的文件儲存在分片中，並且在分片中被索引，但是我們的應用程式不會直接與它們通訊，取而代之的是，直接與索引通訊。 分片是Elasticsearch在叢集中分發資料的關鍵。把分片想象成資料的容器。文件儲存在分片中，然後分片分配到你叢集中的節點上。當你的叢集擴容或縮小，Elasticsearch將會自動在你的節點間遷移分片，以使叢集保持平衡。 分片可以是主分片(primary shard)或者是複製分片(replica shard)。
你索引中的每個文件屬於一個單獨的主分片，所以主分片的數量決定了索引最多能儲存多少資料。 理論上主分片能儲存的資料大小是沒有限制的，限制取決於你實際的使用情況。分片的最大容量完全取決於你的使用狀況：硬體儲存的大小、文件的大小和複雜度、如何索引 和查詢你的文件，以及你期望的響應時間。
複製分片只是主分片的一個副本，它可以防止硬體故障導致的資料丟失，同時可以提供讀請 求，比如搜尋或者從別的shard取回文件。 當索引建立完成的時候，主分片的數量就固定了，但是複製分片的數量可以隨時調整。 讓我們在叢集中唯一一個空節點上建立一個叫做 blogs 的索引。預設情況下，一個索引被分配5個主分片，一個主分片預設只有一個複製分片。
重點：
shard分為兩種：
1，primary shard --- 主分片
2，replica shard --- 複製分片（或者稱為備份分片或者副本分片）
需要注意的是，在業界有一個約定俗稱的東西，單說一個單詞shard一般指的是primary shard，而單說一個單詞replica就是指的replica shard。
另外一個需要注意的是replica shard是相對於索引而言的，如果說當前index有一個複製分片，那麼相對於主分片來說就是每一個主分片都有一個複製分片，即如果有5個主分片就有5個複製分片，並且主分片和複製分片之間是一一對應的關係。
很重要的一點：primary shard不能和replica shard在同一個節點上。重要的事情說三遍：
primary shard不能和replica shard在同一個節點上
primary shard不能和replica shard在同一個節點上
primary shard不能和replica shard在同一個節點上
所以es最小的高可用配置為兩臺伺服器。
三、master節點、協調節點和節點對等特性
elasticsearch同大多數的分散式架構，也會進行主節點的選舉，elasticsearch選舉出來的主節點主要承擔一下工作：
1 叢集層面的設定 2 叢集內的節點維護 3 叢集內的索引、對映（mapping）、分詞器的維護 4 叢集內的分片維護
不同於hadoop、mysql等的主節點，elasticsearch的master將不會成為整個叢集環境的流量入口，即其並不獨自承擔文件級別的變更和搜尋（curd），也就意味著當流量暴增，主節點的效能將不會成為整個叢集環境的效能瓶頸。這就是elasticsearch的節點對等特性。
節點對等：
所謂的節點對等就是在叢集中每個節點扮演的角色都是平等的，也就意味著每個節點都能成為叢集的流量入口，當請求進入到某個節點，該節點就會暫時充當協調節點的角色，對請求進行路由和處理。這是一個區別於其他分散式中介軟體的很重要的特性。節點對等的特性讓elasticsearch具備了負載均衡的特性。在後面對document的寫入和搜尋會詳細介紹該牛叉的特性。
協調節點：
通過上面的分析，我們可以得出一個結論，協調節點其實就是請求命中的那個節點。該節點將承擔當前請求的路由工作。
四、擴容
一般的擴容模式分為兩種，一種是水平擴容，一種是垂直擴容。
4.1、垂直擴容：
所謂的垂直擴容就是升級伺服器，買效能更好的，更貴的然後替換原來的伺服器，這種擴容方式不推薦使用。因為單臺伺服器的效能總是有瓶頸的。
4.2、水平擴容：
水平擴容也稱為橫向擴充套件，很簡單就是增加伺服器的數量，這種擴容方式可持續性強，將眾多普通伺服器組織到一起就能形成強大的計算能力。水平擴容 VS 垂直擴容用一句俗語來說再合適不過了：三個臭皮匠賽過諸葛亮。
4.3、垂直擴容的過程分析
上面我們詳細介紹了分片，master和協調節點，接下來我們通過畫圖的方式一步步帶大家看看橫向擴容的過程。
首先呢需要鋪墊一點關於自定義索引shard數量的操作
1 PUT /student
2 {
3 "settings" : {
4 "number_of_shards" : 3,
5 "number_of_replicas" : 1
6 }
7 }
以上程式碼意味著我們建立的索引student將會分配三個primary shard和三個replica shard（至於上面為什麼是1，那是相對於索引來說的，前面解釋過）。
4.3.1、一臺伺服器
當我們只有一臺伺服器的時候，shard是怎麼分佈的呢？
注：P代表primary shard， R代表replica shard。明確一點在後面的描述中預設一個es節點在一臺伺服器上。
分析一下上面的過程，首先需要明確的兩點：
1，primary shard和replica shard不能再同一臺機器上，因為replica和shard在同一個節點上就起不到副本的作用了。
2，當叢集中只有一個節點的時候，node1節點將成為主節點。它將臨時管理叢集級別的一些變更，例如新建或 刪除索引、增加或移除節點等。
明確了上面兩點也就很簡單了，因為叢集中只有一個節點，該節點將直接被選舉為master節點。其次我們為student索引分配了三個shard，由於只有一個節點，所以三個primary shard都被分配到該節點，replica shard將不會被分配。此時叢集的健康狀況為yellow。
4.3.2、增加一臺伺服器
接著上面繼續，我們增加一臺伺服器，此時shard是如何分配的呢？
Rebalance（再平衡），當叢集中節點數量發生變化時，將會觸發es叢集的rebalance，即重新分配shard。Rebalance的原則就是儘量使shard在節點中分佈均勻，達到負載均衡的目的。
原先node1節點上有p0、p1、p2三個primary shard，另外三個replica shard還未分配，當叢集新增節點node2，觸發叢集的Rebalance，另外三個replica shard將被分配到node2上，即如上圖所示。
此時叢集中所有的primary shard和replica shard都是active（可用）狀態的所以此時叢集的健康狀況為yellow。可見es叢集的最小高可用配置就是兩太伺服器。
4.3.3、繼續新增伺服器
繼續新增伺服器，叢集將再次進行Rebalance，在primary shard和replica shard不能分配到一個節點上的原則，這次rebalance同樣本著使shard均勻分佈的原則，將會從node1上將P1，P2兩個primary shard分配到node1，node2上面，然後將node2在primary shard和replica shard不能分配到一臺機器上的原則上將另外兩個replica shard分配到node1和node2上面。
注意：具體的分配方式上，可能是P0在node2上面也有可能在node3上面，但是隻要本著Rebalance的原則將shard均勻分佈達到負載均衡即可。
五、叢集容災
分散式的叢集是一定要具備容災能力的，對於es叢集同樣如此，那es叢集是如何進行容災的呢？接下來聽我娓娓道來。
在前文我們詳細講解了primary shard和replica shard。replica shard作為primary shard的副本當叢集中的節點發生故障，replica shard將被提升為primary shard。具體的演示如下
叢集中有三臺伺服器，其中node1節點為master節點，primary shard 和 replica shard的分佈如上圖所示。此時假設node1發生宕機，也就是master節點發生宕機。此時叢集的健康狀態為red，為什麼呢？因為不是所有的primary shard都是active的。
具體的容災過程如下：
1，重新選舉master節點，當es叢集中的master節點發生故障，此時es叢集將再次進行master的選舉，選舉出一個新的master節點。假設此時新的主節點為node2。
2，node2被選舉為新的master節點，node2將作為master行駛其分片分配的任務。
3，replica shard升級，此時master節點會尋找node1節點上的P0分片的replica shard，發現其副本在node2節點上，然後將R0提升為primary shard。這個升級過程是瞬間完成的，就像按下一個開關一樣。因為每一個shard其實都是lucene的例項。此時叢集如下所示，叢集的健康狀態為yellow，因為不是每一個replica shard都是active的。
容災的過程如上所示，其實這也是一般分散式中介軟體容災備份的一般手段。如果你很瞭解kafka的話，這個就很容易理解了。
參考文獻：
《elasticsearch-權威指南》
如有錯誤的地方還請留言指正。
原創不易，轉載請註明原文地址：https://www.cnblogs.com/hello-shf/p/11543468.