ES节点类型、选举过程及容灾机制

最新推荐文章于 2024-07-20 14:55:09 发布

!春明!

最新推荐文章于 2024-07-20 14:55:09 发布

阅读量5.6k

点赞数 1

分类专栏： ES 文章标签： elasticsearch

本文链接：https://blog.csdn.net/zcm036200/article/details/122897681

版权

ES 专栏收录该内容

4 篇文章 0 订阅

订阅专栏

一、节点类型

1、主节点（Master）

2、候选节点（Master-eligible node）

三、如何提高ES分布式系统的可用性以及实现性能最大化

四、参考文档

一、节点类型

ES拥有非常完善的容灾机制，在了解容灾之前，我们要先知道ES中各个节点的类型。节点类型的设置可以在配置文件elasticsearch.yml中添加如下属性，只是写了常用的，还有很多类型可以设置，如：冷、暖、热、冻结、摄取节点等。

# 是否为候选节点
node.master: true
# 是否为数据节点
node.data: true
# 是否为投票节点
Node.voting_only = false

按照参数的组装，可以将节点分为如下类型：

1、主节点（Master）

master节点在每个集群中有且只有一个。Master节点应该只承担较为轻量级的任务，比如：创建删除索引，分片均衡等。

# 设置为true
node.master: true
# 尽量设置主节点不为数据节点，提示效率
node.data: false

2、候选节点（Master-eligible node）

和主节点的配置相同，在选举时可以被选举为主节点。

3、数据节点（Data node）

这样的节点主要负责数据存储和一些查询服务。

# 是否为候选节点
node.master: false
# 是否为数据节点
node.data: true

4、协调节点（coordinating）

每一个节点都隐式的是一个协调节点，协调节点既不当候选节点，也不作为数据节点，仅负责负载均衡，进行投票。

# 是否为候选节点
node.master: false
# 是否为数据节点
node.data: false

5、仅投票节点（voting）

设置为仅投票节点后即使配置了data.master = true，也不会参选, 但是仍然可以作为数据节点。

# 是否为投票节点
Node.voting_only = true

6、默认

ES节点默认配置既作为候选节点又作为数据节点，这样的节点一旦被选举为Master，压力是比较大的，通常来说Master节点应该只承担较为轻量级的任务，比如创建删除索引，分片均衡等。

二、master选举

1、脑裂

在master重新选举的过程中，可能会发生脑裂的情况，原master节点并没有挂掉，只是有些节点无法与之取得联系了，此时集群可能存在多个master节点。脑裂对我们的影响主要是导致没有有效的团体存在，所有的团体都不包含多数的表决。

1、产生原因

产生脑裂的原因主要分为俩种：

1、网络波动：集群间的网络延迟导致一些节点访问不到master，认为master挂掉了从而选举出新的master，并对master上的分片和副本标红，分配新的主分片。

2、主节点即是数据节点也是候选节点：访问量较大导致ES响应过慢，使其他节点以为主节点挂掉。或者数据节点上的ES占用进程过大，引发JVM的大规模内存回收，造成ES进程失去响应。

2、预防方法

1、设置候选节点时将数据节点的设置改为false，上面讲解节点分类有距离。

2、将节点状态判断时间加长，默认为3s内没有响应，节点挂掉，适当调大：discovery.zen.ping_timeout:10。

3、增加选举出发的难度，将控制选举行为发生的最小集群主节点数量设大。当备选主节点的个数大于等于该参数，且备选主节点中有该参数个节点认为主节点挂了，进行选举。官方建议为（n/2）+1，n为主节点个数（即有资格成为主节点的节点个数）

： discovery.zen.minimum_master_nodes:3