Elasticsearch集群的脑裂问题

#Elasticsearch集群的脑裂问题 正常状况下，集群中的全部的节点，应该对集群中master的选择是一致的，这样得到的状态信息也应该是一致的，不一致的状态信息，说明不一样的节点对master节点的选择出现了异常——也就是所谓的脑裂问题。这样的脑裂状态直接让节点失去了集群的正确状态，致使集群不能正常工做。

可能致使的缘由：

1. 网络：因为是内网通讯，网络通讯问题形成某些节点认为master死掉，而另选master的可能性较小；进而检查Ganglia集群监控，也没有发现异常的内网流量，故此缘由能够排除。
2. 节点负载：因为master节点与data节点都是混合在一块儿的，因此当工做节点的负载较大（确实也较大）时，致使对应的ES实例中止响应，而这台服务器若是正充当着master节点的身份，那么一部分节点就会认为这个master节点失效了，故从新选举新的节点，这时就出现了脑裂；同时因为data节点上ES进程占用的内存较大，较大规模的内存回收操做也能形成ES进程失去响应。因此，这个缘由的可能性应该是最大的。

应对问题的办法：

1. 对应于上面的分析，推测出缘由应该是因为节点负载致使了master进程中止响应，继而致使了部分节点对于master的选择出现了分歧。为此，一个直观的解决方案即是将master节点与data节点分离。为此，咱们添加了三台服务器进入ES集群，不过它们的角色只是master节点，不担任存储和搜索的角色，故它们是相对轻量级的进程。能够经过如下配置来限制其角色：

node.master: true  
node.data: false

固然，其它的节点就不能再担任master了，把上面的配置反过来便可。这样就作到了将master节点与data节点分离。固然，为了使新加入的节点快速肯定master位置，能够将data节点的默认的master发现方式有multicast修改成unicast：

discovery.zen.ping.multicast.enabled: false  
discovery.zen.ping.unicast.hosts: ["master1", "master2", "master3"]

2. 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台服务器了，这点须要注意）。

discovery.zen.ping.multicast.enabled: false
discovery.zen.ping_timeout: 120s
discovery.zen.minimum_master_nodes: 2 
client.transport.ping_timeout: 60s
discovery.zen.ping.unicast.hosts: ["10.0.31.2", "10.0.33.2"]

https://github.com/elastic/elasticsearch/issues/2488

真的高枕无忧了？ 其实问题依然存在，ES的issue空间也在讨论一个特例状况《#2488》：即便 minimum_master_nodes 设置了一个正确的值，脑裂也有可能发生。

如何识别这个问题？ 在您的集群里面尽快识别这个问题很是重要。一个比较容易的方法是定时获取每个节点/_nodes响应，它返回了集群中全部节点的状态报告，若是两个节点返回的集群状态不同，就是一个脑裂状况发生的警示信号。

新增解决方案 对于一个具备全功能的ES节点，必需要有一个活动的Master节点。ES1.4.0.Beta1后，新增了一项没有Master时阻塞集群操做设置：discovery.zen.no_master_block。

当集群中没有活动的Master节点后，该设置指定了哪些操做（read、write）须要被拒绝（即阻塞执行）。有两个设置值：all和write，默认为wirte。

这项配置不会对基本api（例如集群状态、节点信息和状态API）产生影响，这些节点在任何节点上执行都不会被阻塞。

ps: es的优势：由于它的开箱即用、天生集群、自动容错、扩展性强等优势，仍是选择它来作全文检索