环境:5台安装elasticsearch-5.6.8centos6.9的机器
~5节点的discovery.zen.minimum_master_nodes: 的值都设置为3时,依次启动每台机器,启动不了任何一个节点,因为最先启动的节点发觉它启动的时候没有master节点,即使是它有成为master的资格,但是因为此时集群中没有其他节点为它“投票”[非zookeeper实现],所以启动失败;【但是discovery.zen.ping_timeout设置大一点时可以的】 ~
说起来有些抽象,还是换个思路,先说参数,再说参数设置。
参数解释
几个关键的参数
1.discovery.zen.ping_timeout
2.node.master
3.discovery.zen.minimum_master_nodes
配置时,冒号后面一定要得有空格
discovery.zen.ping_timeout
- discovery.zen.ping_timeout:(默认3秒)。关于这个参数,我有话要说:不少人说是ping的超时时间,朋友们不要看到“timeout”就想到ping不通超时好不好!很误导人的。另外,以下结论仍不够完整或不完全正确,还有很多不解之处,感兴趣的朋友可以看看源码。欢迎留言交流,批评指正。
- 首先,这个参数与master的选举是有很大关联的。在这个时间段中,节点有可能作为slave加入到集群中也有可能被选举为主节点。ping的回调函数需要等待discovery.zen.ping_timeout 这个配置对应的时间才会返回。
- ZenDiscovery类的findMaster开头有这么一句,选主方法调用开始的地方。
ZenPing.PingResponse[] fullPingResponses = pingService.pingAndWait(pingTimeout);
从源代码角度寻求这个答案,参考[1] - 这里我们考虑下这样的情况:现在挂点的节点正好是之前的master,这个时候它要加入,但是有可能它恢复得过快,挂掉后立马请求加入集群,这个时候集群还没有选举出新的master,当主节点停止或遇到问题时,群集节点会再次启动ping并选择新的主节点。
- 在作出选举决定之前,三秒可能不足以让节点意识到其环境中的其他节点。在这种情况下,应该谨慎地增加超时时间,因为这会减慢选举进程。一旦一个节点决定加入一个现有的已形成的集群,它将发送一个加入请求给master,(discovery.zen.join_timeout)默认值是ping_timeout的20倍。
- 所以discovery.zen.ping_timeout 这个参数设置比较大,可以减少master因为负载过重掉出集群的风险。 但同时如果master真出问题了,重新选举过程会很长。
- TODO:什么时候ping?这里的ping与其他大数据解决方案的心跳报告有联系吗?官方说:
ping_interval:How often a node gets pinged. Defaults to 1s.
- 有人说,选举master时,node.master为false的节点的投票是不起作用的,这个说法不完全正确:
如果discovery.zen.master_election.ignore_non_master_pings设置为true,那么以上说法正确,但是默认是false,也就是说,它们的投票是起作用的,只是它们不可能成为master
。所以我觉得,集群机器数不大的话,除了负担特别重的机器,都设置为node.master为true比较妥当。 - 当主节点停止或遇到问题时,群集节点会再次启动ping并选择新的主节点。
- 选举master的时候,会连续发送3次ping测试,顺序是这样的:
- 发送第一轮ping
- shedule第二轮ping,间隔为1/2 timeout时间
- schedule第三轮 ping,间隔为 1/2 timeout时间。
- 第三轮sendpings传递了waitTime参数,其值也是1/2 timeout时间,用于设置countdown latch await时长。如果对每个node的ping测试很快顺利完成,latch countdown应该也是瞬间的,这里几乎没有什么耗时。
- 通知listener结果,结束选主过程。
node.master
见上小节的第7点。
discovery.zen.minimum_master_nodes
- 设置需要加入新一轮master选举的“master”候选人的最小数量
- 也就是说,集群中,该值是针对那些node.master=true的来设置的,建议>=num(node.master