目录
首先单机elasticsearch的问题
搭建es集群
es集群以及脑裂
脑裂现象
coordinator协调节点是如何将文档路由到那个分片上?
es集群新增文档和查询文档流程
总结
故障转移
首先单机elasticsearch的问题
单机es就是一个节点,存储能力是有上限的(比如索引库数据很多);另外如果单机的话,es挂了,数据会丢失;
解决海量数据存储问题:
对索引库的数据进行分片
单点故障问题:
我们可以对每一个节点的数据进行备份,备份的数据放在其他节点上,保证数据的完整性;
搭建es集群
1.首先编写 docker-compose文件
## 4.1.创建es集群
首先编写一个docker-compose文件,内容如下:
```sh
version: '2.2'
services:
es01:
image: elasticsearch:7.12.1 //镜像
container_name: es01 //容器名称
environment:
- node.name=es01 //集群其中一节点名称
- cluster.name=es-docker-cluster //所在集群名称
- discovery.seed_hosts=es02,es03 //另外节点名称
- cluster.initial_master_nodes=es01,es02,es03 //初始化主节点(候选主节点,参与投票)
- "ES_JAVA_OPTS=-Xms512m -Xmx512m"
volumes:
- data01:/usr/share/elasticsearch/data //数据卷
ports:
- 9200:9200 //端口映射
networks:
- elastic
es02:
image: elasticsearch:7.12.1
container_name: es02
environment:
- node.name=es02
- cluster.name=es-docker-cluster
- discovery.seed_hosts=es01,es03
- cluster.initial_master_nodes=es01,es02,es03
- "ES_JAVA_OPTS=-Xms512m -Xmx512m"
volumes:
- data02:/usr/share/elasticsearch/data
ports:
- 9201:9200 //其他端口得不一致
networks:
- elastic
es03:
image: elasticsearch:7.12.1
container_name: es03
environment:
- node.name=es03
- cluster.name=es-docker-cluster
- discovery.seed_hosts=es01,es02
- cluster.initial_master_nodes=es01,es02,es03
- "ES_JAVA_OPTS=-Xms512m -Xmx512m"
volumes:
- data03:/usr/share/elasticsearch/data
networks:
- elastic
ports:
- 9202:9200
volumes:
data01:
driver: local
data02:
driver: local
data03:
driver: local
networks:
elastic:
driver: bridge
```
2.修改linux系统权限内容,进入/etc/sysctl.conf文件
vi /etc/sysctl.conf
3、添加内容
vm.max_map_count=262144
4.然后执行命令,使配置生效
sysctl -p
5.通过docker-compose启动集群,多个容器生成
docker-compose up -d
查看容器
我们可以通过cerboes集群,访问Kibana查看es集群较为复杂,需要依赖x-pack,可以使用cerebro来监控es集群状态
输入es节点的ip
绿色条代表非常健康
es01上面有一个实心代表是一个主节点,空心代表是候选节点
那么回到最初的问题,我们的索引库怎么进行分片呢?每个片带一个交叉备份
解决:我们只需要在创建索引库中设置索引库的分片信息,除了设置自定义分词器外,还能设置分片;
在Kibana创建索引库
PUT /itcast
{
"settings": {
"number_of_shards": 3, // 分片数量
"number_of_replicas": 1 // 副本数量
},
"mappings": {
"properties": {
// mapping映射定义 ...
}
}
}
在cerbo创建索引库
发现索引库itcast成功分成了3片,然后还有3个副本备份,交叉在不同的es机器上,保证了数据的安全;
es集群以及脑裂
ES集群中各个节点的角色规划:
master eligible:主节点配置参数为node.master——>备选主节点,管理和记录集群状态,决定索引库分片给哪些节点,处理创建删除索引库请求;对cpu要求较高
data:数据节点配置参数为node.data——>数据节点,对数据进行存储、搜索、聚合、CRUD,对CPU内存较高
coordinating:协调节点,跟网关类似,路由到其他节点,将其他节点处理的结果返回给用户——>起到负载均衡的作用;
ingest:node.ingest,对数据进行预处理
注意:
我们的节点在es中默认都是配置了的,可能一个节点啥功能都有,但是这样并不好,因为你的CPU、内存有限,肯呢个因为数据的crud而导致主节点挂掉;
所以不同节点要干不同的数,职责分明;
脑裂现象
当出现网络故障时 ,其他节点可能会看不到主节点认为挂掉了,那么此时就会投出新的主节点,当我们用户进行数据的crud,对索引库进行操作时,当网络恢复后,会发现两个主节点数据不一致的情况;
es7.0以后已经默认配置了选票功能,只有>节点数+1/2,才能变为主节点
总结
coordinator协调节点是如何将文档路由到那个分片上?
1.首先进行查询文档
2.发现文档的分片信息(_shared)
那么协调节点是如何计算数据储存到哪个分片上的呢?
es会采用hash算法来计算文档应该存储在哪个分片
_routing默认是文档id(跟map中hash算法中的key类似)
注意:number_of_shards是分片的数量,分片数量发生改变,那么文档的位置就会发生改变,这里一定要注意,分片数量创建就不能再改了,索引库不能再改!
es集群新增文档和查询文档流程
新增文档流程:
当你进行新增文档时,首先先拿到一个协调节点coordinator,它会根据hash算法确定文档路由到哪个分片上,保存文档信息,如果它有副本,就会将文档信息同步给它的副本,然后返回结果给到协调节点coordinator,最后由协调节点总结结果返回给用户
es查询阶段:
我们在之前的query访问可以知道,如果不指定id,访问的话会看到所有的文档——>因为有协调节点的存在,导致es文档时透明可见的;
总结
故障转移
作用:确保整个集群分片数据的伸缩
当主节点宕机,首先从节点会选出一个主节点,然后将宕机节点的分片数据给到其他节点,从而确保数据安全
1.首先停掉es01节点:docker-compose stop 节点名
2.过了一会发现自动故障转移