搭建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节点。

我并没有搜到好的解释为什么重启的节点会分到两个副本分片，理论上来讲应该会分到一个主分片和副本分片。