ElasticSearch 分布式集群

ES学习

第一篇：ElasticSearch 邂逅ES
第二篇：ElasticSearch入门
第三篇：ElasticSearch JavaAPI操作
第四篇：Windows单点和集群配置
第五篇：Linux单点和集群配置
第六篇：ElasticSearch核心概念
第七篇：ElasticSearch系统架构
第八篇：ElasticSearch分布式集群
第九篇：ElasticSearch路由计算

Part5：ElasticSearch进阶

5.3 分布式集群

• 准备材料

  • 这一部分为使用三种类型的ES集群来演示说明下面的内容，分别是一个节点的集群、两个节点的集群、三个节点的集群
  • 这里已经配置好了三种集群，网盘链接供下载（版本7.8.0）
    

• 目录说明（配置文件已经改好，可以直接启动，如果启动失败，删除目录下data和清空logs下文件即可）

  • One：一个节点的集群
  • Two：两个节点的集群
  • Three：三个节点集群

5.3.1 单节点集群

• 使用上述提供的One文件夹下的单节点ES

• 启动单个ES实例，创建一个名称为user的索引，这里设置了三个主分片和一个副本（意味着每个主分片各自都将拥有一个副本分片）
  

• 查看刚刚创建的索引
  

• 目前的集群中是只拥有一个索引的单节点集群。所有三个主分片都被分配在node-1上。（默认ES节点的名称为node-1）
  

• 通过elasticsearch-head插件查看集群情况
  

  • 节点黑边框的是主节点
  • 集群健康值：yellow(3 of 6)：表示当前集群的全部主分片都正常运行，但是副本分片没有全部处在正常状态。
  • 绿色表示3个主分片正常
  • Unassigned：表示副本分片没有被分配到任何节点。在同一个节点上既保存原始数据又保存副本是没有意义的，因为一旦失去了那个节点，也将丢失所有副本数据。

• 当前这种情况下，集群是正常运行的，但是在硬件故障时可能会造成数据丢失。

5.3.2 故障转移

• 使用上述提供的Two文件夹下的两个节点的ES集群，重新建立一下索引和分片设置
  

• 当集群中只有一个节点在运行时，意味着会有一个单点故障问题–没有冗余。解决很简单，我们再启动一个节点就可以防止数据丢失。当同一台机器启动了第二个节点，只要和第一个节点的cluster.name的配置相同，就会自动发现集群并加入到其中。但是在不同机器上启动节点时，如果想要加入到同一集群，就需要配置一个可连接到的单播主机列表。之所以配置为使用单播发现，是为了防止节点无意中加入到集群中。只有在同一台机器上运行的节点才会自动组成集群。

• 如果启动了第二个节点，我们的集群将会拥有两个节点的集群，这样的话，所有的主分片和副本分片都会被分配。
  

• 通过elasticsearch-head插件查看集群情况
  

  • 节点黑边框的是主节点
  • 集群健康值：green（6 of 6)：表示所有6个分片（包括3个主分片和3个副本分片）都在正常运行
  • 当第二个节点加入到集群中后，3个副本分片将会分配到这个节点上—每个主分片对应一个副本分片。这意味着当集群内任何一个节点出现问题时，我们的数据都完好无损。所有最新被索引的文档都会被保存在主分片上，然后被并行的复制到对应的副本分片上。这就保证了我们既可以从主分片又可以从副本分片上获得文档。

5.3.3 水平扩容

• 使用上述提供的Three文件夹下的三个节点的ES集群，重新建立一下索引和分片设置
  

• 由于数据量在一个系统内都会持续增长的？那么如果根据数据需求进行扩容呢？（按此时的分片规则）当我们启动第三个节点时，我们的集群将会变成拥有三个节点的集群：为了分散负载而对分片进行重新分配。
  

• 通过elasticsearch-head插件查看集群情况
  

  • green：表示所有6个分片（3个主分片和3个副本分片）都正常运行
  • 在节点上的分片重新进行了规划，每个节点上只有2个分片，不是之前两个节点集群中的情况了。这样的分配会使用每个节点上的硬件资源（CPU、RAM、I/O）将被更少的分片所共享，每个分片的性能得到了提升。
  • 分片是一个功能完整的搜索引擎，它拥有使用一个节点上的所有资源的能力。我们目前拥有6个分片（3主3副）的索引最大可以扩容到6个节点，每个节点上存在一个分片，并且每个分片拥有所在节点的全部资源。

• Question：当前三个节点的集群设置为3个分片，副本数为1，一共3主+3副=6个分片，如果想扩容超过6个节点怎么办？

  • 主分片的数量在索引创建的时候就已经被确定下来了。实际上，这个数量定义了这个索引能够存储的最大数据量（实际大小取决于数据、硬件和使用场景，因为副本分片只是作为主分片的备份，实际存储量还是看主分片个数来决定）。但是，对于读操作（如搜索和返回数据）都可以同时被主分片或者副本分片所处理，所以当你拥有越多的副本分片时，也将拥有越高的吞吐量。

  • 副本分片的数量是可以在创建后进行调整的。可以根据需要伸缩集群。这里把副本分片数从1添加到2
    

  • 此时user索引会拥有9个分片：3主和6副。这就意味着我们最多可以将集群扩容到9个节点，每个节点上一个分片。和之前3个节点时，集群的搜索性能可以提高3倍。

  • 使用elasticsearch-head查看
    

  • 反之，在相同节点上，增加副本分片数量并不能提高性能。因为这样做的话，每个分片从该节点上获得资源就会变少，需要增加更多硬件资源来提升吞吐量。过多的副本分片数量提高了数据的冗余度（因为备份很多次）：在上面的节点配置上，在失去两个节点的情况下不会丢失任何数据。

5.3.4 应对故障

• 首先看一下，当前集群的状态情况
  

• 现在我们开始制造“故障”，关闭node-2，此时集群变成了关闭了一个节点的集群。

  • 从图中可以看出，我们关闭的节点有这样的特征（主节点，含有三个主分片）。需要明确一点是，ES集群中必须拥有一个主节点才能保证正常工作，在我们关闭node-2时，意味着原有的主节点消失了，此时集群要做的第一件事就是在存活节点中选举出一个新的主节点。此外，node-2中含有3个主分片，关闭它意味着三个主分片也丢失了，缺失了主分片的索引也无法正常工作。如果关闭node-2的时刻尽快检查集群状态，发现是red。因为不是所有的主分片都正常工作。
    

  • 有同学可能很奇怪，不是会变成red吗？为啥再次查询时是yellow。因为ES选举新的主节点的过程是瞬时的，如同按下开关一般。单纯通过页面再次请求是不能监测到的。

• es自身调整：因为其他存活节点上存在着丢失主分片的完整副本，所以新选举出的主节点会立刻将node-1和node-3上对应的副本分片提升为主分片。此时集群状态会变成yellow。

• Question：为什么此时集群状态为yellow不是green？

  • 因为索引的设置是3个主分片和副本分片数是2个，共9个分片，但是此时每个主分片只存在一个副本分片，所以并非所有的副本分片都能正常工作，因此为yellow。但是这种情况没必要担心，因为即便此时关闭了Node-1（保存副本分片），ES集群依旧可以正常运行，因为node-3上保存着所有的主分片。

• 此时，如果重新启动node-1，集群可以将缺失的副本分片再次重新分配，这样集群的状态就变成green了。如果node-1依然持有之前的分片，它将尝试去重用，然后仅仅需要主从复制发生了修改的数据文件即可。这样和之前的集群相比，仅仅是master节点改变了

  • 
    据文件即可。这样和之前的集群相比，仅仅是master节点改变了