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

目录

一、节点类型 

1、主节点（Master）

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

3、数据节点（Data node）

4、协调节点（coordinating）

5、仅投票节点（voting）

6、默认

二、master选举 

1、脑裂

1、产生原因

 2、预防方法

3、后续解决

二、容灾机制

三、如何提高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

3、后续解决

        上述方案其实是预防脑裂的出现，如果脑裂已经发生了，如何解决呢？我想到的方法就是重启集群，有大神可以留言帮助一下。

二、容灾机制

        ES集群因为分片和副本的存在使ES集群的可用性非常高。ES集群不可用的原因主要是因为主节点的宕机，所以ES的容灾机制依靠的就是master选举、、分片以及副本。

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

        .....

四、参考文档

        1、马士兵课程