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节点改变了