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天然就是集群狀態。
1、把ES的安裝包分發給其他兩台機器
2、根據第一台機器的linux系統配置，修改其他兩台機子
3、在三台機器能夠獨立啟動的情況下，修改/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
輸入地址登陸（登陸任何一個節點的IP都可以）： http://192.168.1.101:9200
3. 集群操作原理
集群：
一個節點(node)就是一個Elasticsearch實例，而一個集群(cluster)由一個或多個節點組成，它們具有相同的cluster.name，它們協同工作，分享數據和負載。
當加入新的節點或者刪除一個節點時，集群就會感知到並平衡數據。
集群節點
1、集群中一個節點會被選舉為主節點(master)
2、臨時管理集群級別的一些變更，例如新建或刪除索引、增加或移除節點等。
3、主節點不參與文檔級別的變更或搜索，這意味着在流量增長的時候，該主節點不會成為集群的瓶頸。
4、任何節點都可以成為主節點。
5、用戶，我們能夠與集群中的任何節點通信，包括主節點。
6、每一個節點都知道文檔存在於哪個節點上，它們可以轉發請求到相應的節點上。
7、我們訪問的節點負責收集各節點返回的數據，最后一起返回給客戶端。這一切都由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（r1、r2）| p1（r0、r2）| p3（r0、r2），p0、p1和p3是一份數據拆分成了3片存儲到3台機器中（負載均衡），如果一個分片有兩個副本，那么任何一個機器宕了，都可以正常使用，提高了容錯性！！計算的時候跟mr有點相似，先把每個片中的數據全算完了之后，再去找台機器做合並，合並之后再給用戶；（好處三個分片可以同時進行計算，並行度提高）
索引只是一個用來指向一個或多個分片(shards)的“邏輯命名空間(logical namespace)”.
分片(shard)是一個最小級別“工作單元(worker unit)”,它只是保存了索引中所有數據的一部分，是一個Lucene實例，並且它本身就是一個完整的搜索引擎。我們的文檔存儲在分片中，並且在分片中被索引，但是我們的應用程序不會直接與它們通信，取而代之的是，直接與索引通信。
分片是Elasticsearch在集群中分發數據的關鍵。把分片想象成數據的容器。文檔存儲在分片中，然后分片分配到你集群中的節點上。當你的集群擴容或縮小，Elasticsearch將會自動在你的節點間遷移分片，以使集群保持平衡。
1、主分片
索引中的每個文檔屬於一個單獨的主分片，所以主分片的數量決定了索引最多能存儲多少數據。
理論上主分片能存儲的數據大小是沒有限制的，限制取決於你實際的使用情況。分片的最大容量完全取決於你的使用狀況：硬件存儲的大小、文檔的大小和復雜度、如何索引和查詢你的文檔，以及你期望的響應時間。
2、副分片
副分片只是主分片的一個副本，它可以防止硬件故障導致的數據丟失，同時可以提供讀請求，比如搜索或者從別的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主節點--->然后返回給客戶端。
對於讀請求，為了平衡負載，請求節點會為每個請求選擇不同的分片——它會循環所有分片副本。
可能的情況是，一個被索引的文檔已經存在於主分片上卻還沒來得及同步到復制分片上。這時復制分片會報告文檔未找到，主分片會成功返回文檔。一旦索引請求成功返回給用戶，文檔則在主分片和復制分片都是可用的。
若查詢副本切片，它在兩個不同分片上，兩個復制分片會發給主分片，由主分片進行合並去響應客戶端；
