ElasticSearch初探之所有初次使用记录（八）关于ES集群master选举的几个关键参数的小测验

环境：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不通超时好不好！很误导人的。另外，以下结论仍不够完整或不完全正确，还有很多不解之处，感兴趣的朋友可以看看源码。欢迎留言交流，批评指正。
  
  1. 首先，这个参数与master的选举是有很大关联的。在这个时间段中，节点有可能作为slave加入到集群中也有可能被选举为主节点。ping的回调函数需要等待discovery.zen.ping_timeout 这个配置对应的时间才会返回。
  2. ZenDiscovery类的findMaster开头有这么一句，选主方法调用开始的地方。
     ZenPing.PingResponse[] fullPingResponses = pingService.pingAndWait(pingTimeout);
     从源代码角度寻求这个答案，参考[1]
  3. 这里我们考虑下这样的情况：现在挂点的节点正好是之前的master，这个时候它要加入，但是有可能它恢复得过快，挂掉后立马请求加入集群，这个时候集群还没有选举出新的master，当主节点停止或遇到问题时，群集节点会再次启动ping并选择新的主节点。
  4. 在作出选举决定之前，三秒可能不足以让节点意识到其环境中的其他节点。在这种情况下，应该谨慎地增加超时时间，因为这会减慢选举进程。一旦一个节点决定加入一个现有的已形成的集群，它将发送一个加入请求给master，（discovery.zen.join_timeout）默认值是ping_timeout的20倍。
  5. 所以discovery.zen.ping_timeout 这个参数设置比较大，可以减少master因为负载过重掉出集群的风险。 但同时如果master真出问题了，重新选举过程会很长。
  6. TODO:什么时候ping?这里的ping与其他大数据解决方案的心跳报告有联系吗？官方说:ping_interval:How often a node gets pinged. Defaults to 1s.
  7. 有人说，选举master时，node.master为false的节点的投票是不起作用的，这个说法不完全正确：如果discovery.zen.master_election.ignore_non_master_pings设置为true，那么以上说法正确，但是默认是false，也就是说，它们的投票是起作用的，只是它们不可能成为master。所以我觉得，集群机器数不大的话，除了负担特别重的机器，都设置为node.master为true比较妥当。
  8. 当主节点停止或遇到问题时，群集节点会再次启动ping并选择新的主节点。
  9. 选举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=true)/2+1.并不是有的朋友解释的，集群机器数量的除以2再加1，当然默认情况下是，因为默认情况下，discovery.zen.master_election.ignore_non_master_pings为false

当一个新的节点启动时，将该启动的节点传递给这个列表中指定的主机，以便与它们执行discovery.zen（Pass an initial list of hosts to perform discovery when new node is started）
可否理解为与hdoop中的image、edits文件的机制类似？方便备用namenode“登基”时获得之前的一些“集群节点信息”（非HA）
- 所以该列表，应该时所有node.master=true的hosts。【考虑到传递给slave，也就是node.master=false的节点也没有坏处，所以我觉得这里填集群所有hosts也不是不可以】

参数测试

一、设置 ip13、14两个节点为node.master=true，其他3个为false，discovery.zen.ping.unicast.hosts为ip13、14，discovery.zen.minimum_master_nodes: 3

同时启动5个ES节点

节点启动时，首先对节点的数据环境进行检查：

[2018-05-20T19:25:25,395][INFO ][o.e.n.Node] [es-ip14] initializing ...
[2018-05-20T19:25:25,513][INFO ][o.e.e.NodeEnvironment] [es-ip14] using [2] data paths, mounts [[/home (/dev/mapper/vg_ip14-lv_home)]], net usable_space [723.5gb], net total_space [762.4gb], spins? [possibly], types [ext4]

然后是JVM相关参数检查：

[es-ip14] JVM arguments [-Xms2g, -Xmx2g, -XX:+UseConcMarkSweepGC, -XX:CMSInitiatingOccupancyFraction=75, -XX:+UseCMSInitiatingOccupancyOnly, -XX:+AlwaysPreTouch, -Xss1m, -Djava.awt.headless=true, -Dfile.encoding=UTF-8, -Djna.nosys=true, -Djdk.io.permissionsUseCanonicalPath=true, -Dio.netty.noUnsafe=true, -Dio.netty.noKeySetOptimization=true, -Dio.netty.recycler.maxCapacityPerThread=0, -Dlog4j.shutdownHookEnabled=false, -Dlog4j2.disable.jmx=true, -Dlog4j.skipJansi=true, -XX:+HeapDumpOnOutOfMemoryError, -Des.path.home=/home/guest/elasticsearch-5.6.8]

再然后加载ES自身组件，加载插件
检查发现新节点的类型，启动ES

1. 可成为master的节点打印的日志信息：【master节点数不满足设置的最小数量3，仅发现2个Candidate】
   
2. slave打印的信息：与上面的日志无本质区别

---

一台一台的启动

1. 启动candidate master ip13，打印的日志信息：
   【只找到一个candidate master，也就是自己】

[2018-05-20T19:56:46,486][WARN ][o.e.d.z.ZenDiscovery     ] [es-ip13] not enough master nodes discovered during pinging (found [[Candidate{node={es-ip13}{HJXdtOZLQ-yg4_bcSJF4pA}{J8XfYnIISlugp52wne3Yig}{1**.***.***.***}{1**.***.***.***:9300}, clusterStateVersion=-1}]], but needed [3]), pinging again

2.启动candidate master ip14，打印的日志信息：
【与上方无本质区别，仅找到一个candidate master，也就是自己】
3.启动slave的节点打印的日志信息：
【一个master都找不见，found 0，need 3】

[es-ip10] not enough master nodes discovered during pinging (found [[]], but needed [3]), pinging again

猜测：
1.所有节点都会向所有discovery.zen.ping.unicast.hosts中设置的host进行“汇报”，尝试与之相ping，或成为master或加入；

结论：
1.各个ES在初始化的时候，就在互相ping,并不需要到完全启动了才能ping
2.集群的各个节点启动时，都检验master是否存在，存在则作为slave加入，不存在则检查candidate master是否满足设置的值，存在则进行选举，不存在则报错，无法启动节点

二、discovery.zen.ping.unicast.hosts增加ip12，但是node.master依然为false，重复一中步骤：

【与一的实验结果无任何本质区别】

结论：
1.node.master=false，但是host在discovery.zen.ping.unicast.hosts列表中，不参与master竞选，但是可能接受新节点的“报告”

三、ip12的node.master设置为true，但是discovery.zen.ping.unicast.hosts中依然只设置ip13/ip14，重复一中步骤：

【所有节点启动成功】
1.除了被选举成功的ip14打印new_master，其他所有节点打印：detected_master

结论：
1.节点是否参与master选举与参数discovery.zen.ping.unicast.hosts无关

四、基于三，将ip10、11的discovery.zen.master_election.ignore_non_master_pings设置为true，并设置master candidate仅ip13、ip14，discovery.zen.minimum_master_nodes: 2

【启动成功,且打印日志与测验三一样】
结论：
1.candidate master自身也投了票
2.的默认值3秒还是挺够用的

杀死master或者candidate master，所有节点宕机，not enough master nodes discovered during pinging（这里只有2个candidate master，最小数也设置的2），恢复slave的投票权结果不变

杀死一个slave，所有active节点均打印removed消息，discovery.zen.ping.unicast.hosts到底作用在何处？

五、discovery.zen.ping_timeout设置为60秒，依次启动节点

1.
timed out while waiting for initial discovery state - timeout: 30s
但是节点是能启动的
2.逐渐启动完所有集群：（10-11-12-13-14的顺序）
发现ip13被选举为master，
ip14加入集群

六、最终测试：

discovery.zen.ping.unicast.hosts: ["ip10","ip11","ip12","ip13", "ip14"]
#
# Prevent the "split brain" by configuring the majority of nodes (total number of master-eligible nodes / 2 + 1):
#
discovery.zen.minimum_master_nodes: 3
#
# For more information, consult the zen discovery module documentation.
#
# ---------------------------------- Gateway -----------------------------------
#
# Block initial recovery after a full cluster restart until N nodes are started:
#
#gateway.recover_after_nodes: 3
#
# For more information, consult the gateway module documentation.
#
# ---------------------------------- Various -----------------------------------
#
# Require explicit names when deleting indices:
#
#action.destructive_requires_name: true
node.master: false
node.data: true
#http.cors.enabled: true
#http.cors.allow-origin: "*"
# discovery.zen.master_election.ignore_non_master_pings: true
discovery.zen.ping_timeout: 60s

结论：
1.杀掉一个candidate master，没有影响（如果是kill掉active master，将会从剩下的3个candidate master选出一个；再kill一个candidate master，报错）
2.杀掉一个candidate master/active master时，其他节点继续工作，再kill一个candidate master，报错，但是剩余的节点仍然继续工作。

图为选举出新的master

TODO

1.看源码，什么时候zen.timeout?
2.单播discovery.zen.ping.unicast.hosts不需要禁用多播吗？看源码，单播如何体现（实现）的。
3.什么时候ping?这里的ping与”心跳报告“有关吗？

参考

[1] 源码理解参数-discovery.zen.ping_timeout
[2] http://www.easyice.cn/archives/164
[3]官网discover doc