ElasticSearch集群

高可用性

集群解决的问题

基本上所有的单机问题都有

• 并发压力
• 响应时间
• 磁盘空间问题
• 宕机

Elasticsearch 信息存储机制

• 分片
  Elasticsearch 中一个索引（Index）相当于是一个数据库，它是被分片存储的，Elasticsearch 默认会把一个索引分成五个分片，当然这个数字是可以自定义的。

  分片是数据的容器，数据保存在分片内，分片又被分配到集群内的各个节点里。当你的集群规模扩大或者缩小时， Elasticsearch 会自动的在各节点中迁移分片，使得数据仍然均匀分布在集群里，所以相当于一份数据被分成了多份并保存在不同的主机上。

• 数据备份
  Elasticsearch 默认会生成默认五个原分片和五个分片副本（可以自定义），相当于一份数据存了两份，并分了十个分片。

  只需要将某个分片的副本存在另外一台主机上，这样当某台主机宕机了，可以从另外一台主机的副本中找到对应的数据。

• 返回

  ES会将搜索在各个节点的结果聚合返回 如下图
  
  一旦有多个节点挂掉，只剩一台就不会提供服务

健康状态

针对一个索引，Elasticsearch 中其实有专门的衡量索引健康状况的标志，分为三个等级：

green，绿色。这代表所有的主分片和副本分片都已分配。你的集群是 100% 可用的。

yellow，黄色。所有的主分片已经分片了，但至少还有一个副本是缺失的。不会有数据丢失，所以搜索结果依然是完整的。不过，你的高可用性在某种程度上被弱化。如果更多的分片消失，你就会丢数据了。所以可把 yellow 想象成一个需要及时调查的警告。

red，红色。至少一个主分片以及它的全部副本都在缺失中。这意味着你在缺少数据：搜索只能返回部分数据，而分配到这个分片上的写入请求会返回一个异常。

搭建 Elasticsearch 集群

使用docker compose 搭建单机集群

搭建分布式集群

docker-compose.yml

version: '3'
services:
  elasticsearch:                    # 服务名称
    image: elasticsearch:7.3.1      # 使用的镜像
    container_name: elasticsearch   # 容器名称
    restart: always                 # 失败自动重启策略
    environment:                                    
      - node.name=41  # 节点名称，集群模式下每个节点名称唯一
      - network.publish_host=172.168.50.41  # 用于集群内各机器间通信,其他机器访问本机器的es服务
      - network.host=0.0.0.0                # 设置绑定的ip地址，可以是ipv4或ipv6的，默认为0.0.0.0，
      - discovery.seed_hosts=172.168.50.40,172.168.50.240,172.168.50.41  # es7.x 之后新增的配置，写入候选主节点的设备地址，在开启服务后可以被选为主节点
      - cluster.initial_master_nodes=172.168.50.40,172.168.50.240,172.168.50.41  # es7.x 之后新增的配置，初始化一个新的集群时需要此配置来选举master
      - cluster.name=es-cluster   # 集群名称，相同名称为一个集群
      - http.cors.enabled=true    # 是否支持跨域，是：true
      - http.cors.allow-origin="*" # 表示支持所有域名
      - bootstrap.memory_lock=true  # 内存交换的选项，官网建议为true
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m" # 设置内存
    ulimits:
      memlock:
        soft: -1
        hard: -1
    ports:
      - 9200:9200
      - 9300:9300

集群面临的常见问题

分片与副本丢失

如果主分片和副分片都丢失了，则可以使用Elasticsearch的快照和还原模块尽可能多地恢复丢失的数据

数据节点磁盘空间不够了

低磁盘使用空间有两种补救措施。

（1）删除过时的数据。 这对所有用户来说可能不是一个可行的选择，但是如果您正在存储基于时间的数据，则可以存储旧索引数据的快照，用于备份，同时更新索引设置以关闭这些过时索引的副本功能。
（2）如果你需要所有的数据都存在集群中备用，要么升级硬件资源（vertically scale ）、要么水平扩展集群（horizontally scale增加节点，这个是比较合适的）。为了更好适应数据不断的增长，应该要多指定主分片的个数。

搜索执行时间过长怎么办？

如何加快我的index速度

参考