Elasticsearch集群
單點的問題
單台服務器，往往都有最大的負載能力，超過這個閾值，服務器性能就會大大降低甚至不可用。單點的elasticsearch也是一樣，那單點的es服務器存在哪些可能出現的問題呢？
-
單台機器存儲容量有限
-
單服務器容易出現單點故障，無法實現高可用
-
單服務的並發處理能力有限
所以，為了應對這些問題，我們需要對elasticsearch搭建集群
數據分片
首先，我們面臨的第一個問題就是數據量太大，單點存儲量有限的問題。
大家覺得應該如何解決？
沒錯，我們可以把數據拆分成多份，每一份存儲到不同機器節點（node），從而實現減少每個節點數據量
數據備份
數據分片解決了海量數據存儲的問題，但是如果出現單點故障，那么分片數據就不再完整，這又該如何解決呢？
沒錯，就像大家為了備份手機數據，會額外存儲一份到移動硬盤一樣。我們可以給每個分片數據進行備份，存儲到其它節點，防止數據丟失，這就是數據備份，也叫數據副本（replica）。
數據備份可以保證高可用，但是每個分片備份一份，所需要的節點數量就會翻一倍，成本實在是太高了！
為了在高可用和成本間尋求平衡，我們可以這樣做：
-
首先對數據分片，存儲到不同節點
-
然后對每個分片進行備份，放到對方節點，完成互相備份
這樣可以大大減少所需要的服務節點數量，如圖，我們以3分片，每個分片備份一份為例
在這個集群中，如果出現單節點故障，並不會導致數據缺失，所以保證了集群的高可用，同時也減少了節點中數據存儲量。並且因為是多個節點存儲數據，因此用戶請求也會分發到不同服務器，並發能力也得到了一定的提升。
搭建集群
集群需要多台機器，我們這里用一台機器來模擬，因此我們需要在一台虛擬機中部署多個elasticsearch節點，每個elasticsearch的端口都必須不一樣。
我們計划集群名稱為：heima-elastic，部署3個elasticsearch節點，分別是：
-
node-01：http端口9201，TCP端口9301
-
node-02：http端口9202，TCP端口9302
-
node-03：http端口9203，TCP端口9303
接下來的所有操作，記得要使用elastic用戶來操作！
另外，建議先對當前虛擬機進行快照，以后好恢復成單點結構。
1.清空elasticsearch中的數據
首先把已經啟動的elasticsearch關閉，然后通過命令把之前寫入的數據都刪除。
rm -rf /elasticsearch/data
2.修改elasticsearch配置
進入/home/elastic/elasticsearch/config目錄，修改elasticsearch.yml文件
vim elasticsearch.yml
內容修改成這樣：
# ======================== Elasticsearch Configuration ========================= # 集群名稱,三台服務器保持一致 cluster.name: heima-elastic # # 節點名稱，每個節點唯一標識 node.name: node-01 # # 數據目錄 path.data: /home/elastic/elasticsearch-01/data # # 日志目錄 path.logs: /home/elastic/elasticsearch-01/logs # # 綁定的ip，0.0.0.0，代表任意ip地址均可訪問 network.host: 0.0.0.0 # # http協議的對外端口 http.port: 9201 # # TCP協議對外端口，一般是集群內部通訊使用 transport.tcp.port: 9301 # # 集群中其它節點的ip及端口 discovery.zen.ping.unicast.hosts: ["127.0.0.1:9301", "127.0.0.1:9302","127.0.0.1:9303"] # # 選舉主節點時需要看到最少多少個具有master資格的活節點，才能進行選舉。官方的推薦值是(N/2)+1 discovery.zen.minimum_master_nodes: 2
3.復制elasticsearch節點
回到 /home/elastic 目錄，將elasticsearch目錄修改為ealsticsearch-01`：
mv elasticsearch elasticsearch-01
然后輸入下面命令，拷貝兩份elasticsearch實例：
cp elasticsearch-01 elasticsearch-02 -R cp elasticsearch-01 elasticsearch-03 -R
進入elasticsearch-02/config目錄，修改elasticsearch.yml中的下列配置：
# 節點名稱 node.name: node-02 # # 數據目錄 path.data: /home/elastic/elasticsearch-02/data # # 日志目錄 path.logs: /home/elastic/elasticsearch-02/logs # # http協議的對外端口 http.port: 9202 # # TCP協議對外端口 transport.tcp.port: 9302
同理，進入elasticsearch-3/config/，修改elasticsearch.yml文件，與上面類似，不過修改成03.
4.啟動並測試
./elasticsearch-01/bin/elasticsearch -d ./elasticsearch-02/bin/elasticsearch -d ./elasticsearch-03/bin/elasticsearch -d
通過啟動運行chrome的 elasticsearch-head插件，可以查看到節點信息：
5 啟動錯誤
啟動錯誤1：
原因是：是因為復制的elasticsearch文件夾下包含了data文件中示例一的節點數據，需要把示例二data文件下的文件清空。刪除es集群data數據庫文件夾下所有文件即可
啟動錯誤2：
於elasticsearch6.8默認分配jvm空間大小為1g，虛擬機內存不夠大，修改jvm空間分配128m或256m、512m,最少需要128m
6 集群健康
可以通過elasticsearch-head插件查看集群健康狀態，有以下三個狀態：
green
- 所有的主分片和副本分片都已分配。你的集群是 100% 可用的。
yellow
- 所有的主分片已經分片了，但至少還有一個副本是缺失的。不會有數據丟失，所以搜索結果依然是完整的。不過，你的高可用性在某種程度上被弱化。如果 更多的 分片消失，你就會丟數據了。把
yellow想象成一個需要及時調查的警告。
red
- 至少一個主分片（以及它的全部副本）都在缺失中。這意味着你在缺少數據：搜索只能返回部分數據，而分配到這個分片上的寫入請求會返回一個異常
測試集群中創建索引庫
搭建集群以后就要創建索引庫了，那么問題來了，當我們創建一個索引庫后，數據會保存到哪個服務節點上呢？如果我們對索引庫分片，那么每個片會在哪個節點呢？
這個要親自嘗試才知道。
還記得創建索引庫的API嗎？
-
請求方式：PUT
-
請求路徑：/索引庫名
-
請求參數：json格式：
{
"settings": {
"屬性名": "屬性值"
}
}
-
settings：就是索引庫設置，其中可以定義索引庫的各種屬性，目前我們可以不設置，都走默認。
這里給搭建看看集群中分片和備份的設置方式，示例：
PUT /heima3
{
"settings": {
"number_of_shards": 3,
"number_of_replicas": 1
}
}
這里有兩個配置：
-
number_of_shards：分片數量，這里設置為3
-
number_of_replicas：副本數量，這里設置為1，每個分片一個備份，一個原始數據，共2份。
通過chrome瀏覽器的head查看，我們可以查看到分片的存儲結構：
可以看到，heima這個索引庫，有三個分片，分別是0、1、2，每個分片有1個副本，共6份。
-
node-01上保存了0號分片和1號分片的副本
-
node-02上保存了1號分片和2號分片的副本
-
node-03上保存了0號分片和2號分片的副本