搭建ES集群
目录
前言
搭建ES集群
集群状态监控
分片备份
节点角色
脑裂问题
分布式存储
分布式查询
故障转移
前言
单机的ES做数据存储必然会面临两个问题:海量数据存储问题、单机故障问题
海量数据存储问题:将索引库从逻辑上拆分为N个分片(shard),存储到多个节点。
单机故障问题:将分片数据在不同节点备份(replica)
搭建ES集群
在Docker中部署三个ES节点。请确保虚拟机存在至少4G运行内存。
下面是docker-compose文件的内容
version: '2.2'
services:es01:image: elasticsearch:7.12.1container_name: es01environment:- 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/dataports:- 9200:9200networks:- elastices02:image: elasticsearch:7.12.1container_name: es02environment:- 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/dataports:- 9201:9200networks:- elastices03:image: elasticsearch:7.12.1container_name: es03environment:- 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/datanetworks:- elasticports:- 9202:9200
volumes:data01:driver: localdata02:driver: localdata03:driver: localnetworks:elastic:driver: bridge
修改虚拟机配置
vi /etc/sysctl.conf
vm.max_map_count = 262144
#max_map_count文件包含限制一个进程可以拥有的VMA(虚拟内存区域)的数量
保存后刷新配置文件
sysctl -p
使用docker-compose启动三个容器
docker-compose up -d
集群状态监控
处理在浏览器访问9200、9201、9202端口外,还能使用一种ES集群可视化工具Cerebro。我们选择win版本的可视化工具。
下载地址为:Tags · lmenezes/cerebro (github.com)
启动时如果报错加载缓存错误,更换JDK版本即可。在cerebro.bat文件中添加如下代码
双击启动运行图如下
访问9000端口。
输入集群其中一个节点即可连接整个集群。节点名称前面的星号实心代表是主节点,空心代表是候选节点。
分片备份
可以使用Kibana或Cerebro来实现。
如果使用Kibana实现分片,那么在创建索引库时指定
PUT /索引库名
{"settings":{"number_of_shards":3, //分片数量"number_of_replicas":1//副本数量
},"mappings":{}
}
使用Cerebro时,则如下图所示
创建完成后
节点角色
节点类型 | 配置参数 | 默认值 | 节点职责 |
master eligible | node.master | true | 备选主节点:主节点可以管理和记录集群状态,决定分片在哪个节点,处理创建和删除索引库的请求 |
data | node.data | true | 数据节点:存储数据,搜索、聚合、CRUD |
ingest | node.ingest | true | 数据存储之前的预处理 |
coordinating | 上面3个参数都为false则为coordinating节点 | 无 | 协调节点:路由请求到其他节点,合并其他节点处理的结果,返回给用户 |
如果没有配置,每个节点四个职责都会处理,但是在生产环境,通常不会这样。每个节点都是单一职责。其次通常不需要ingest节点,数据预处理通常在Java代码中完成,不会让ES去做。
脑裂问题
默认情况下,每个节点都是master eligible节点,因此一旦master节点宕机,其他候选节点会选举一个成为主节点,但是当主节点与其他节点网络故障时,可能会发生脑裂问题。
当候选主节点无法连接到主节点时,会从候选主节点中选举一个重新作为主节点。。去实现索引库的增删。当网络恢复时,集群中就出现了2个主节点,且两个节点的数据不一致。
为了避免出现脑裂问题,需要要求选票超过(候选节点数量+1)/2才能成为主节点。
当开始重新选举主节点时,node1会投自己一票,由于node2与node3连接不上node1。因此,node2与node3中会选举出一个主节点。如果node2与node3都投node3节点为主节点,那么(3+1)/2 = 2。node3成为主节点,node1成为候选主节点。
候选主节点数量最好为奇数。对应配置项是discovery.zen.minimum_master_nodes,在es7版本之后,已经成为一个默认配置,因此一般不会发生脑裂问题。
分布式存储
测试向之间创建的索引库插入数据三条数据。
接下来查询数据。
可以看到在9200节点增加的数据在9201也可以查询。添加配置查询每个数据都存储在哪些节点上
每条数据会被存储到哪个分片是由coordinating决定的。具体算法如下
说明
- _routing默认是文档id
- 算法与分片数量有关,因此索引库一旦创建,分片数量不能修改
分布式查询
ES的查询分为两个阶段:
- scatter phase:分散阶段,协调节点会把请求分发到每一个分片中
- gather phase:聚集阶段,协调节点汇总数据节点的搜索结果,并处理为最终结果集返回给用户
故障转移
集群中master节点会监控集群中的节点状态,如果发现有节点宕机,会立即将宕机节点的分片数据迁移到其他节点,确保数据安全。
测试:
接下来重启es01节点。
我并没有搜到好的解释为什么重启的节点会分到两个副本分片,理论上来讲应该会分到一个主分片和副本分片。