ES集羣

1. ElasticSerach集羣安裝

 修改配置文件elasticserach.yml

[elk@localhost config]$ vi elasticsearch.yml   
# ---------------------------------- Cluster -----------------------------------
# Use a descriptive name for your cluster:
cluster.name: my-es   #集羣中機器的name必須相同 

# Use a descriptive name for the node:
node.name: node-1 ##集羣中各個節點的名字（必須不一樣） 
#指定了該節點可能成爲 master 節點，還能夠是數據節點（Cent-os6上沒配置它）
node.master: true 
node.data: true

# Path to directory where to store the data (separate multiple locations by comma):
path.data: /home/elk/es/data
# Path to log files:
path.logs: /home/elk/es/logs

# Set the bind address to a specific IP (IPv4 or IPv6):
network.host: 192.168.1.101 # 當前節點的IP地址，每一個機器的host是不同的 
# Set a custom port for HTTP: ##（CentOS6沒配置它）
http.port: 9200  # 對外提供服務的端口
transport.tcp.port: 9300  #9300爲集羣服務的端口,各個節點之間互相通訊

# The default list of hosts is ["127.0.0.1", "[::1]"] ##自發現配置，新節點向集羣報到的主機名
discovery.zen.ping.unicast.hosts: ["192.168.1.102", "192.168.1.103"] #集羣中節點IP地址，也可使用域名，須要各節點可以解析；不能寫本機的，本身不能和本身通訊 

# Prevent the "split brain" by configuring the majority of nodes (total number of master-eligible nodes / 2 + 1):
discovery.zen.minimum_master_nodes: 2 # 爲了不腦裂，集羣節點數最少爲 半數+1 CestOS6沒配置

# ----------------------------------- Memory -----------------------------------
#
# Lock the memory on startup:  把bootstrap自檢程序關掉
#
bootstrap.memory_lock: false
bootstrap.system_call_filter: false

######學習中修改下JVM的內存，默認是2G
[kris@hadoop101 config]$ vim jvm.options    

-Xms256m
-Xmx256m

修改linux配置
爲何要修改linux配置？
默認elasticsearch是單機訪問模式，就是隻能本身訪問本身。
可是咱們以後必定會設置成容許應用服務器經過網絡方式訪問。這時，elasticsearch就會由於嫌棄單機版的低端默認配置而報錯，甚至沒法啓動。
因此咱們在這裏就要把服務器的一些限制打開，能支持更多併發。

問題1：max file descriptors [4096] for elasticsearch process likely too low, increase to at least [65536] elasticsearch
緣由：系統容許 Elasticsearch 打開的最大文件數須要修改爲65536
解決：vi /etc/security/limits.conf
添加內容：
* soft nofile 65536
* hard nofile 131072
* soft nproc 2048
* hard nproc 65536
 
注意：「*」 不要省略掉
 
問題2：max number of threads [1024] for user [judy2] likely too low, increase to at least [2048]  （CentOS7.x  不用改）
 
緣由：容許最大進程數修該成4096
解決：vi /etc/security/limits.d/90-nproc.conf   
修改以下內容：
* soft nproc 1024
#修改成
 * soft nproc 4096
 
問題3：max virtual memory areas vm.max_map_count [65530] likely too low, increase to at least [262144] （CentOS7.x  不用改）
緣由：一個進程能夠擁有的虛擬內存區域的數量。
解決： 
在   /etc/sysctl.conf  文件最後添加一行
vm.max_map_count=262144
便可永久修改

把修改的linux配置記得分發到其餘機器中；xsync xxx

重啓linux

es自然就是集羣狀態。

　　一、把ES的安裝包分發給其餘兩臺機器

　　二、根據第一臺機器的linux系統配置，修改其餘兩臺機子

　　三、在三臺機器可以獨立啓動的狀況下，修改/etc/elasticsearch/elasticsearch.yml

設置新主機的「報道中心」就好了

　　1 node-xx

　　2 network-host hadoop1

還要記得把 三臺主機的node.name改爲各自的

 

檢查集羣是否正確啓動

http://192.168.1.101:9200/_cat/nodes?v
{"error":{"root_cause":[{"type":"master_not_discovered_exception","reason":null}],"type":"master_not_discovered_exception","reason":null},"status":503}

http://192.168.1.101:9200/

http://192.168.1.101:9200/_cat/nodes?v
ip heap.percent ram.percent cpu load_1m load_5m load_15m node.role master name
192.168.1.102 7 96 10 0.39 0.41 0.19 mdi * node-1
192.168.1.101 7 96 8 0.28 0.37 0.20 mdi - node-2

注意yml配置文件中key: value格式冒號後面要跟一個空格。不然程序會報錯；

注意：若是data和logs地址設爲elasticsearch中的data和logs，則要清空data和logs數據；建議新建一個其餘的目錄
IP設置爲1.0有可能和1.1之間通訊時選擇不了master！換成1.101和1.102

2. ES集羣管理工具Cerebro

可在windows環境下直接啓動
cerebro-0.8.1\bin\cerebro.bat

訪問：http://localhost:9000/

 輸入地址登錄（登錄任何一個節點的IP均可以）： http://192.168.1.101:9200 

 

3. 集羣操做原理

集羣：
一個節點(node)就是一個Elasticsearch實例，而一個集羣(cluster)由一個或多個節點組成，它們具備相同的cluster.name，它們協同工做，分享數據和負載。
當加入新的節點或者刪除一個節點時，集羣就會感知到並平衡數據。

集羣節點
　　一、集羣中一個節點會被選舉爲主節點(master)
　　二、臨時管理集羣級別的一些變動，例如新建或刪除索引、增長或移除節點等。
　　三、主節點不參與文檔級別的變動或搜索，這意味着在流量增加的時候，該主節點不會成爲集羣的瓶頸。
　　四、任何節點均可以成爲主節點。
　　五、用戶，咱們可以與集羣中的任何節點通訊，包括主節點。
　　六、每個節點都知道文檔存在於哪一個節點上，它們能夠轉發請求到相應的節點上。
　　七、咱們訪問的節點負責收集各節點返回的數據，最後一塊兒返回給客戶端。這一切都由Elasticsearch處理。
集羣健康情況
在Elasticsearch集羣中能夠監控統計不少信息，可是隻有一個是最重要的：集羣健康(cluster health)。集羣健康有三種狀態：green、yellow或red。
在一個沒有索引的空集羣中運行如上查詢，將返回這些信息：
GET /_cluster/health  或者GET _cat/health?v  

{
    "cluster_name": "elasticsearch",
    "status": "green", 
    "timed_out": false,
    "number_of_nodes": 1,
    "number_of_data_nodes": 1,
    "active_primary_shards": 0,
    "active_shards": 0,
    "relocating_shards": 0,
    "initializing_shards": 0,
    "unassigned_shards": 0
}

status字段提供一個綜合的指標來表示集羣的的服務情況。三種顏色各自的含義：

顏色    　　    意義
green   　　 全部主要分片和複製分片均可用； 都得保證每一個索引都得有副本；GET _cat/indices?v 查看索引的情況
　　好比3臺機器中，r0（r2的副本）、 r1（r0的副本）、 r2（r1的副本)主要數據，若是r2機器宕了，它的副本還在，容錯性提升，這樣子狀況下就是green狀態；

yellow   　　全部主要分片可用，但不是全部複製分片均可用，至少是副本不足； 默認副本數replication是一個；
　　GET _cat/shards/索引名稱 ；yellow是主片都還在，可是副本缺失，只有一份數據；（缺失副本有可能磁盤空間不足了：df -h）

red   　　 不是全部的主要分片均可用

集羣分片

　　p0（r一、r2）| p1（r0、r2）| p3（r0、r2），p0、p1和p3是一份數據拆分紅了3片存儲到3臺機器中（負載均衡），若是一個分片有兩個副本，那麼任何一個機器宕了，均可以正常使用，提升了容錯性！！計算的時候跟mr有點類似，先把每一個片中的數據全算完了以後，再去找臺機器作合併，合併以後再給用戶；（好處三個分片能夠同時進行計算，並行度提升）
　　索引只是一個用來指向一個或多個分片(shards)的「邏輯命名空間(logical namespace)」.

分片(shard)是一個最小級別「工做單元(worker unit)」,它只是保存了索引中全部數據的一部分，是一個Lucene實例，而且它自己就是一個完整的搜索引擎。咱們的文檔存儲在分片中，而且在分片中被索引，可是咱們的應用程序不會直接與它們通訊，取而代之的是，直接與索引通訊。
分片是Elasticsearch在集羣中分發數據的關鍵。把分片想象成數據的容器。文檔存儲在分片中，而後分片分配到你集羣中的節點上。當你的集羣擴容或縮小，Elasticsearch將會自動在你的節點間遷移分片，以使集羣保持平衡。

　　一、主分片
　　索引中的每一個文檔屬於一個單獨的主分片，因此主分片的數量決定了索引最多能存儲多少數據。
理論上主分片能存儲的數據大小是沒有限制的，限制取決於你實際的使用狀況。分片的最大容量徹底取決於你的使用情況：硬件存儲的大小、文檔的大小和複雜度、如何索引和查詢你的文檔，以及你指望的響應時間。
　　二、副分片
　　副分片只是主分片的一個副本，它能夠防止硬件故障致使的數據丟失，同時能夠提供讀請求，好比搜索或者從別的shard取回文檔。

當索引建立完成的時候，主分片的數量就固定了，可是副分片的數量能夠隨時調整。
只能增長副分片，不能增長主分片
建立分片：

PUT /blogs
{
   "settings" : {
      "number_of_shards" : 3,
      "number_of_replicas" : 1
   }
}

增長副分片：
PUT /blogs/_settings
{
   "number_of_replicas" : 2
}

集羣的健康狀態yellow表示全部的主分片(primary shards)啓動而且正常運行了——集羣已經能夠正常處理任何請求——可是複製分片(replica shards)尚未所有可用。事實上全部的三個複製分片如今都是unassigned狀態——它們還未被分配給節點。在同一個節點上保存相同的數據副本是沒有必要的，若是這個節點故障了，那全部的數據副本也會丟失。

主節點：
臨時管理集羣級別，不參與文檔級別的變動
自動選舉主節點， 用戶訪問主節點，主節點再去分配讓它去哪一個節點

主節點至關於路由功能，負載平衡

建立索點擊頁面中的more-->:

①
name: my_cluster
number of shards:2
number of replicas:2
主分片2(實心-主分片和空心-副分片)，副本2  
(2個節點(nodes)，2個主分片(shards)，2個副本(replicas)，集羣中一共8個分片(shards))
開闢內存空間，把索引分紅1和0兩個分片; 每個主分片中都有兩個2分，兩個副分片不可用，就報黃色
2*(1主+2個副本),一個主只需一個副本便可，另一個不須要unassigned shards; 兩個nodes即2個副本不可用就會報黃色預警；

可添加一個機器，好比可加到0分片上；

副本分片，保證了集羣的高可用，

 

 

②
分片依賴於索引
name: my-es
number of shards:3
number of replicas:1
3個主分片，每一個節點包含3個不一樣的分片

 

③
4    2    -->    (黃色預警) 
name: mycluster2
number of shards:4
number of replicas:2
給它設置爲1個副分片就變成green了；
PUT /mycluster2/_settings
{
  "number_of_replicas": 1
}
---->
{
  "acknowledged": true
}

 

④
6    1 
3-->6個分片，1個主分片只能有1個副本
一共12個節點；增長了節點的存儲量，再添加副本加進去就沒意義了；

故障轉移
在單一節點上運行意味着有單點故障的風險——沒有數據備份。幸運的是，要防止單點故障，咱們惟一須要作的就是啓動另外一個節點。
第二個節點已經加入集羣，三個複製分片(replica shards)也已經被分配了——分別對應三個主分片，這意味着在丟失任意一個節點的狀況下依舊能夠保證數據的完整性。
文檔的索引將首先被存儲在主分片中，而後併發複製到對應的複製節點上。這能夠確保咱們的數據在主節點和複製節點上均可以被檢索。

集羣操做原理
路由

當你索引一個文檔，它被存儲在單獨一個主分片上。Elasticsearch是如何知道文檔屬於哪一個分片的呢？當你建立一個新文檔，它是如何知道是應該存儲在分片1仍是分片2上的呢？
進程不能是隨機的，由於咱們未來要檢索文檔。
算法決定：shard = hash(routing) % number_of_primary_shards
routing值是一個任意字符串，它默認是_id但也能夠自定義。

爲何主分片的數量只能在建立索引時定義且不能修改？
若是主分片的數量在將來改變了，全部先前的路由值就失效了，文檔也就永遠找不到了。

全部的文檔API（get、index、delete、bulk、update、mget）都接收一個routing參數，它用來自定義文檔到分片的映射。自定義路由值能夠確保全部相關文檔——例如屬於同一我的的文檔——被保存在同一分片上。

操做數據節點工做流程
每一個節點都有能力處理任意請求。每一個節點都知道任意文檔所在的節點，因此也能夠將請求轉發到須要的節點。
執行：先在主節點路由--->其餘節點上(具體哪一個節點由算法決定：routing是默認文檔id)  算法： shard = hash(routing) % number_of_primary_shards主分片數，PUT的數據存儲在哪一個分片上也是這個算法決定；

主分片(數)若是修改了，以前存的路由表就都失效了；這個算法取餘數，值變了路由表就會變，就會亂了；

新建、索引和刪除請求都是寫(write)操做，它們必須在主分片上成功完成才能複製到相關的複製分片上。

　　1. 客戶端給Node 1發送新建、索引或刪除請求。
　　2. 節點使用文檔的_id肯定文檔屬於分片0。它轉發請求到Node 3，分片0位於這個節點上。
　　3. Node 3在主分片上執行請求，若是成功，它轉發請求到相應的位於Node 1和Node 2的複製節點上。當全部的複製節點報告成功，Node 3報告成功到請求的節點，請求的節點再報告給客戶端。

數據同步，R0 R0(P0的副本)；並非同步完以後才能查詢；若同步失敗，數據不一致了； 同步失敗，會有超時時間，啓動副本節點；異步操做(開線程)

replication
複製默認的值是sync。這將致使主分片獲得複製分片的成功響應後才返回。
若是你設置replication爲async，請求在主分片上被執行後就會返回給客戶端。它依舊會轉發請求給複製節點，但你將不知道複製節點成功與否。
上面的這個選項不建議使用。默認的sync複製容許Elasticsearch強制反饋傳輸。async複製可能會由於在不等待其它分片就緒的狀況下發送過多的請求而使Elasticsearch過載。
檢索流程
文檔可以從主分片或任意一個複製分片被檢索。(複製節點 也提供查詢功能)

　　1. 客戶端給Node 1發送get請求。
　　2. 節點使用文檔的_id肯定文檔屬於那個分片，主分片0對應的複製分片在三個節點上都有。此時，它轉發請求到Node 2。
　　3. Node 2返回文檔(document)給Node1主節點--->而後返回給客戶端。
　　對於讀請求，爲了平衡負載，請求節點會爲每一個請求選擇不一樣的分片——它會循環全部分片副本。
可能的狀況是，一個被索引的文檔已經存在於主分片上卻還沒來得及同步到複製分片上。這時複製分片會報告文檔未找到，主分片會成功返回文檔。一旦索引請求成功返回給用戶，文檔則在主分片和複製分片都是可用的。

若查詢副本切片，它在兩個不一樣分片上，兩個複製分片會發給主分片，由主分片進行合併去響應客戶端；