当前位置:   article > 正文

分布式搜索引擎ES--Elasticsearch集群_es分布式搜索用几台服务器合适,,每台里面有啥属性

es分布式搜索用几台服务器合适,,每台里面有啥属性

1.Elasticsearch集群的概念

分片机制:每个索引都可以被分片
索引my_doc只有一个主分片;索引shop有三个主分片;索引shop2有5个主分片;(参考前面案例)
每个主分片都包含索引的数据,由于目前是单机,所以副分片是没有的,集群健康值显示为黄色。
副分片是主分片的备份;同一个分片的主与副本是不会放在同一个服务器里的,因为一旦宕机,这个分片就没了;
Es集群搭建的准备工作:
使用虚拟机克隆功能,把单个es虚拟机克隆为三个,我们会搭建3节点的es集群。
在这里插入图片描述
如上图。当有三个服务器,首先对主分片分布服务器。副分片不能跟主分片在同一服务器

2.搭建Elasticsearch集群

具体的Elasticsearch的安装参考如下链接:
https://blog.csdn.net/TOMORROW6COME/article/details/140529958?spm=1001.2014.3001.5501
准备了3个服务器。(或者三个虚拟机)
克隆以后,先将es中的打他目录,一定要清空,这里面包含了原先的索引库数据。
命令:rm nodes/ -rf
在这里插入图片描述
配置集群
修改elasticsearch.yml这个配置文件如下:

# 配置集群名称,保证每个节点的名称相同,如此就能都处于一个集群之内了
cluster.name: nk-es-cluster

# 每一个节点的名称,必须不一样
node.name: es-node1

# http端口(使用默认即可)
http.port: 9200

# 主节点,作用主要是用于来管理整个集群,负责创建或删除索引,管理其他非master节点(相当于企业老总)
node.master: true

# 数据节点,用于对文档数据的增删改查
node.data: true

# 集群列表
discovery.seed_hosts: ["192.168.1.184", "192.168.1.185", "192.168.1.186"]

# 启动的时候使用一个master节点
cluster.initial_master_nodes: ["es-node1"]
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20

最后可以通过如下命令查看配置文件的内容:

more elasticsearch.yml | grep ^[^#]
  • 1

分别启动3台es
切换到esuser后在启动,访问集群各个节点,查看信息:

http://192.168.1.184:9200/
http://192.168.1.185:9200/
http://192.168.1.186:9200/

3.Elasticsearch集群分片测试

配置信息:
a:1/0; b:3/1; c:5/2:
集群分片测试:第一个分片不一定在master节点
在这里插入图片描述

4.Elasticsearch集群节点宕机测试

Node2宕机测试:
在这里插入图片描述
Node1:master主节点宕机测试:经过选举es-node3成为maser节点
在这里插入图片描述
宕机恢复后:
在这里插入图片描述
此时node3宕机:es-node2经过选举成为主节点
在这里插入图片描述
node3恢复后,node2任然为主节点。

5.Elasticsearch集群脑裂现象讨论

脑裂:发生网络中断或者服务器宕机,那么集群会有可能划成两个部分,各自有
自己的master节点来管理。
在这里插入图片描述
最小投票人数:1,即一台服务器就是主节点

脑裂解决方案
master主节点要经过多个master节点共同选举后才能成为新的主节点。就跟班级里选班长一样,并不是你1个人能决定的,需要班里半数以上的人决定。

解决实现原理:半数以上的节点同意选举,节点方可成为新的master。

discovery.zen.minimum_master_nodes=(N/2)+1
  • 1

N为集群的中master节点的数量,也就是那些 node.master=true 设置的那些服务器节点总数。
ES 7.X
在最新版7.x中,minimum_master_node这个参数已经被移除了,这一块内容完全由es自身去管理,这样就避免了脑裂的问题,选举也会非常快。

6.Elasticsearch集群的文档读写原理

文档写原理:
客户端会根据情况选择一个节点去完成相应的对接工作(协调节点:coordinating node);
协调节点是可变的
用于接收用户的请求(controller),针对节点进行路由,然后hash计算,决定数据应该写到哪一个主分片里;(文档路由跟转发)
在这里插入图片描述
文档读原理:
在这里插入图片描述

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/秋刀鱼在做梦/article/detail/975701
推荐阅读
相关标签
  

闽ICP备14008679号