ELasticsearch的集群是由多个节点组成的,通过cluster.name设置集群名称,并且用于区分其它的集群,每个节点通过node.name指定节点的名称。
在Elasticsearch中,节点的类型主要有4种:
master节点
data节点
客户端节点
部落节点
准备3个服务器:
192.168.40.137、192.168.4.138、192.168.40.150
所有以下配置需要在配置文件中保持唯一,如果有重复的,则会报错
#启动3个虚拟机,分别在3台虚拟机上部署安装Elasticsearch
mkdir -p /opt/elk
#将之前单机安装的elasearch分发到其它机器
scp -r elsearch/ [email protected]:/opt/elk/
scp -r elsearch/ [email protected]:/opt/elk/
#node01的配置==>192.168.40.150
cluster.name: es-cluster
node.name: node01
network.host: 0.0.0.0
http.port: 9200
discovery.seed_hosts: ["192.168.40.137","192.168.40.138","192.168.40.150"]
cluster.initial_master_nodes: ["node01", "node02", "node03"]
# 最小节点数
node.roles: [master,data]
# 跨域专用
http.cors.enabled: true
http.cors.allow-origin: "*"
#node02的配置:
cluster.name: es-cluster
node.name: node02
network.host: 0.0.0.0
http.port: 9200
discovery.seed_hosts: ["192.168.40.137","192.168.40.138","192.168.40.150"]
cluster.initial_master_nodes: ["node01", "node02", "node03"]
# 最小节点数
node.roles: [master,data]
#node03的配置:
cluster.name: es-cluster
node.name: node03
network.host: 0.0.0.0
http.port: 9200
discovery.seed_hosts: ["192.168.40.137","192.168.40.138","192.168.40.150"]
cluster.initial_master_nodes: ["node01", "node02", "node03"]
# 最小节点数
node.roles: [master,data]
#分别启动3个节点
./elasticsearch
查看集群
查询集群状态:/_cluster/health
响应如下:
集群中有三种颜色
为了将数据添加到Elasticsearch,我们需要索引(index)——一个存储关联数据的地方。实际上,索引只是一个用来指向一个或多个分片(shards)的“逻辑命名空间(logical namespace)”.
一个分片(shard)是一个最小级别“工作单元(worker unit)”,它只是保存了索引中所有数据的一部分。
分片可以是主分片(primary shard)或者是复制分片(replica shard)。
索引中的每个文档属于一个单独的主分片,所以主分片的数量决定了索引最多能存储多少数据。
复制分片只是主分片的一个副本,它可以防止硬件故障导致的数据丢失,同时可以提供读请求,比如搜索或者从别的shard取回文档。
当索引创建完成的时候,主分片的数量就固定了,但是复制分片的数量可以随时调整。
当前集群状态为黄色,表示主节点可用,副本节点不完全可用,过一段时间观察,发现节点列表中看不到node01,副本节点分配到了node02和node03,集群状态恢复到绿色。
将node01恢复:./bin/elasticsearch
可以看到,node01恢复后,重新加入了集群,并且重新分配了节点信息。
将node02停止,也就是将主节点停止。
从结果中可以看出,集群对master进行了重新选举,选择node03为master。并且集群状态会变成黄色,
等待一段时间后,集群状态从黄色变为了绿色:
恢复node02节点:
./bin/elasticsearch
重启之后,发现node02可以正常加入到集群中,集群状态依然为绿色:
特别说明:
如果在配置文件中node.roles: [master,data]设置的不是N/2+1时,会出现脑裂问题,之前宕机的主节点恢复后不会加入到集群。
首先,来看个问题:
如图所示:当我们想一个集群保存文档时,文档该存储到哪个节点呢? 是随机吗? 是轮询吗?实际上,在ELasticsearch中,会采用计算的方式来确定存储到哪个节点,计算公式如下:
shard = hash(routing) % number_of_primary_shards
其中:
这就是为什么创建了主分片后,不能修改的原因。
新建、索引和删除请求都是写(write)操作,它们必须在主分片上成功完成才能复制分片上
下面我们罗列在主分片和复制分片上成功新建、索引或删除一个文档必要的顺序步骤:
客户端接收到成功响应的时候,文档的修改已经被应用于主分片和所有的复制分片。你的修改生效了。
下面罗列在主分片或复制分片上检索一个文档必要的顺序步骤:
对于读请求,为了平衡负载,请求节点会为每个请求选择不同的分片,它会循环所有分片副本。
可能的情况是,一个被索引的文档已经存在于主分片上却还没来得及同步到复制分片上。这时复制分片会报告文档未找到,主分片会成功返回文档。一旦索引请求成功返回给用户,文档则在主分片和复制分片都是可用的。
对于全文搜索而言,文档可能分散在各个节点上,那么在分布式的情况下,如何搜索文档呢?
搜索,分为2个阶段,
搜索(query)
取回(fetch)
查询阶段包含以下三步:
分发阶段由以下步骤构成: