现象
同时出现多个master
访问不同的节点,会发现集群状态不一样,可用节点数不一样
可能的原因
节点负载
master节点同时扮演master和data角色的话,当工作节点负载太大或者遇到full gc ,导致对es实例响应停止响应,
这个时候其它节点以为master挂了,然后重新选举master,这个时候出现两个master 。
应对办法
一、避免master节点因为工作负载过大出现响应中断从而引发脑裂
①集群中设置3台以上的节点作为master节点【node.master: true node.data: false】。这些节点只负责成为主节点,维护整个集群的状态。节点(角色)类型解释:node.master和node.data
node.master: true
node.data: false
②再根据数据量设置一批data节点【node.master: false node.data: true】。这些节点只负责存储数据。
③后期提供建立索引和查询索引的服务,如果用户请求比较频繁,这些节点的压力也会比较大。所以在集群中建议再设置一批client节点【node.master: false node.data: false】。这些节点只负责处理用户请求,实现请求转发,负载均衡等功能。
二、为了使新加入的节点快速确定master位置,可以将data节点的默认的master发现方式由multicast(多播)修改为unicast(单播):
discovery.zen.ping.multicast.enabled: false
discovery.zen.ping.unicast.hosts: ["master1", "master2", "master3"]
三、discovery.zen.ping_timeout(默认值是3秒):默认情况下,一个节点会认为,如果master节点在3秒之内没有应答,那么这个节点就是死掉了,而增加这个值,会增加节点等待响应的时间,从一定程度上会减少误判。
四、discovery.zen.minimum_master_nodes(默认是1):这个参数控制的是,一个节点需要看到的具有master节点资格的最小数量,然后才能在集群中做操作。官方的推荐值是(N/2)+1,其中N是具有master资格的节点的数量(我们的情况是3,因此这个参数设置为2,但对于只有2个节点的情况,设置为2就有些问题了,一个节点DOWN掉后,你肯定连不上2台服务器了,这点需要注意)。