1、ES集群介紹

單機的ES做數(shù)據(jù)存儲與搜索，必然面臨兩個問題：

• 海量數(shù)據(jù)存儲問題
• 單點故障問題

因此，考慮使用ES集群：

• 海量數(shù)據(jù)存儲問題：將索引庫從邏輯上拆分為N個分片（shard），存儲到多個節(jié)點。如此，ES的存儲能力就是所有節(jié)點存儲能力的總和
  

• 單點故障問題：將分片數(shù)據(jù)在不同的節(jié)點備份（replica），即主分片和副本分片不能在同一個節(jié)點
  

2、搭建ES集群

利用3個docker容器模擬3個es的節(jié)點：

• 首先編寫 docker-compoes.yml文件，內容：

version: '2.2'
services:
  es01:
    image: docker.elastic.co/elasticsearch/elasticsearch:7.12.1
    container_name: es01
    environment:
      - node.name=es01  
      - cluster.name=es-docker-cluster  # 這里集群名稱一樣，集群名稱相同的節(jié)點會形成集群
      - discovery.seed_hosts=es02,es03  # 集群中另外兩個節(jié)點的IP，但這里我用容器模擬了，用容器名就能互連
      - cluster.initial_master_nodes=es01,es02,es03  # 集群有主從之分，這三個節(jié)點參與選舉，產生主節(jié)點
      - bootstrap.memory_lock=true
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
    ulimits:
      memlock:
        soft: -1
        hard: -1
    volumes:
      - data01:/usr/share/elasticsearch/data
    ports:
      - 9200:9200
    networks:
      - elastic  # 網(wǎng)絡
  es02:
    image: docker.elastic.co/elasticsearch/elasticsearch:7.12.1
    container_name: es02
    environment:
      - node.name=es02
      - cluster.name=es-docker-cluster
      - discovery.seed_hosts=es01,es03
      - cluster.initial_master_nodes=es01,es02,es03
      - bootstrap.memory_lock=true
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
    ulimits:
      memlock:
        soft: -1
        hard: -1
    volumes:
      - data02:/usr/share/elasticsearch/data
	ports:
      - 9201:9200  # 宿主機9200已用，這里+1
    networks:
      - elastic
  es03:
    image: docker.elastic.co/elasticsearch/elasticsearch:7.12.1
    container_name: es03
    environment:
      - node.name=es03
      - cluster.name=es-docker-cluster
      - discovery.seed_hosts=es01,es02
      - cluster.initial_master_nodes=es01,es02,es03
      - bootstrap.memory_lock=true
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
    ulimits:
      memlock:
        soft: -1
        hard: -1
    volumes:
      - data03:/usr/share/elasticsearch/data
    networks:
      - elastic
	ports:
      - 9202:9200

volumes:
  data01:
    driver: local
  data02:
    driver: local
  data03:
    driver: local

networks:
  elastic:
    driver: bridge

• es運行需要修改一些linux系統(tǒng)權限，修改/etc/sysctl.conf文件：

vi /etc/sysctl.conf

• 添加內容：

vm.max_map_count=262144

• 生效配置：

sysctl -p

• 通過docker-compose啟動集群：

docker-compose up -d

# yum install docker-compose

3、集群狀態(tài)監(jiān)控

kibana可以監(jiān)控es集群，但新版需要依賴es的x-pack功能，配置復雜，這里用cerebro來監(jiān)控es集群狀態(tài)

# 官網(wǎng)
https://github.com/lmenezes/cerebro

# 網(wǎng)盤
鏈接：https://pan.baidu.com/s/1dj4HgTZsVfFSe6-hR2ydnA?pwd=9527 
提取碼：9527

• 下載完成后解壓
  

• 進入bin，雙擊cerebro.bat
  

• 訪問localhost:9000，輸入任一節(jié)點的地址（地址后面有個/）
  
  

創(chuàng)建索引庫

集群中，每個索引庫的分片數(shù)量、副本數(shù)量都是在創(chuàng)建索引庫時指定的，并且分片數(shù)量一旦設置以后無法修改。

語法如下：

PUT /test
{
  "settings": {
    "number_of_shards": 3, // 分片數(shù)量
    "number_of_replicas": 1 // 副本數(shù)量
  },
  "mappings": {
    "properties": {
      // mapping映射定義 ...
    }
  }
}

在cerebro中創(chuàng)建索引庫：

填索引庫名和分片數(shù)、副本數(shù)：

查看overview，實線為主分片，虛線為副本分片：

4、集群職責及腦裂

集群節(jié)點職責：

ES集群中，不同的節(jié)點有不同的職責：

以上角色的默認值都為ture，但不同的角色職責不同，對硬件的要求也不同，有的對CPU要求高，有的對硬盤要求高，因此，應該每個節(jié)點都有自己獨立的角色。舉個例子如下圖，每個節(jié)點專門干一件事：

腦裂：

默認情況下，每個節(jié)點都是master eligible節(jié)點，因此一旦master節(jié)點宕機，其它候選節(jié)點會選舉一個成為主節(jié)點。但當主節(jié)點只是與其他節(jié)點有暫時的網(wǎng)絡通信故障時：

備選節(jié)點聯(lián)系不上主節(jié)點，以為主節(jié)點宕機，選舉出一個新的master，由此產生兩個主節(jié)點，當網(wǎng)絡恢復，就會出現(xiàn)數(shù)據(jù)不一致的情況。

為了避免腦裂，需要要求選票超過 ( eligible節(jié)點數(shù)量 + 1 ）/ 2 才能當選為主，因此eligible節(jié)點數(shù)量最好是奇數(shù)。對應配置項是discovery.zen.minimum_master_nodes 。在es7.0以后，已經成為默認配置，因此一般不會發(fā)生腦裂問題

5、分布式新增和查詢流程

沒啟動kibana，直接調接口插入三條doc：（在9201，即es01節(jié)點插入數(shù)據(jù)）

查詢文檔，不管在9201、9202、9203，三個節(jié)點都能查到數(shù)據(jù)：

添加explain參數(shù)來看分片情況：三條數(shù)據(jù)在不同的分片

這是協(xié)調節(jié)點工作的結果，當新增文檔時，它會將數(shù)據(jù)保存到不同分片，保證數(shù)據(jù)均衡。而coordinating node確實數(shù)據(jù)存到哪個分片是根據(jù)：

• _routing默認是文檔的id
• number_of_shards即分片數(shù)量，算法與分片數(shù)量有關，因此索引庫一旦創(chuàng)建，分片數(shù)量不能修改

存儲和查詢都依賴這個算法，因此分片數(shù)量不能再變，否則按某個分分片數(shù)量存進去后，分片數(shù)量改變，等查的時候按這個算法計算找文檔就找不到了。

新增文檔流程：

當然，根據(jù)id查詢，還是這么個流程。但如果不知道文檔id，該怎么查，比如match_all

ES集群的分布式查詢

• scatter phase：分散階段，coordinating node會把請求分發(fā)到每一個分片
• gather phase：聚集階段，coordinating node匯總data node的搜索結果，并處理為最終結果集返回給用戶

coordinating node可能為其中任一個節(jié)點，就像上面match_all查詢，不管訪問哪個節(jié)點，最終都可以拿到三條數(shù)據(jù)。

6、ES故障轉移

集群的master節(jié)點會監(jiān)控集群中的節(jié)點狀態(tài)，如果發(fā)現(xiàn)有節(jié)點宕機，會立即將宕機節(jié)點的分片數(shù)據(jù)遷移到其它節(jié)點，確保數(shù)據(jù)安全，即故障轉移。比如有條數(shù)據(jù)，存于三個節(jié)點的主分片分別為P-0、P-1、P-2，副本為R-0、R-1、R-2，此時node1節(jié)點宕機：

當然R0+P1+P2還是可以湊出這條數(shù)據(jù)，但此時數(shù)據(jù)已經不安全，需要遷移：

實際模擬一下，此時三個節(jié)點都正常，數(shù)據(jù)存在三分節(jié)點上：

//停掉es1容器，模擬節(jié)點宕機
docker stop es01

查看集群情況：變黃了，不健康了，數(shù)據(jù)分片0有兩個（主副都在），但1、2分片都只有一個了

再等等，開始了數(shù)據(jù)遷移了：

重新啟動es01，查看效果：

docker start es01

分片回去了，數(shù)據(jù)還是均衡的，但es01已不再是主節(jié)點。這倒有點想Redis的哨兵模式。

總結：

文章來源地址http://www.zghlxwxcb.cn/news/detail-560874.html

到了這里，關于【ElasticSearch】ES集群搭建、監(jiān)控、故障轉移的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！