ElasticSearch集群出现脑裂

Elasticsearch部分节点不能发现集群(脑裂)问题处理

现象描述

es版本 1.4.5+centos 6.5

es1,es2,es3三台es组成一个集群，集群状态正常，

当es1 服务器重启后，es1不能加到集群中，自己选举自己为master,这就产生了es集群中所谓的“脑裂”, 把es1的es服务重启后，es1则能正常发现集群并加入。
当重启es2服务器后，es2不能加到集群中，自己选举自己为master,也产生了es集群中所谓的“脑裂”,当重启es服务后，还是不能发现集群。
当重启es3服务器后，es3能加到集群中。正常。

分析

三台es服务器es服务，插件的版本均一样，配置除了节点名不同也一样。

查看es服务的启动日志发现：
[2015-07-22 16:48:24,628][INFO ][cluster.service          ] [Es_node_10_0_31_2] new_master [Es_node_10_0_31_2][fDJA3kUtTHC7eJuS4h78FA][localhost][inet[/10.0.31.2:9300]]{rack=rack2, master=true}, reason: zen-disco-join (elected_as_master)
服务启动过程中，由于未能发现集群，自己选举自己为master
导致该问题有可能网络原因。因为discovery.zen(es 中一个集群的服务）超时了还没有找到集群则选举自己为master。
修改设置 discovery.zen.ping_timeout: 30s，原来10s 重启es1发现正常了。用同样的方法修改es2,发现不凑效
修改es2的设置如下：
discovery.zen.ping.multicast.enabled: false
discovery.zen.ping_timeout: 120s
discovery.zen.minimum_master_nodes: 2 #至少要发现集群可做master的节点数，
client.transport.ping_timeout: 60s
discovery.zen.ping.unicast.hosts: ["10.0.31.2", "10.0.33.2"]  指明集群中其它可能为master的节点ip,以防找不到
用该方法后，重启es2服务器能正常发现集群，服务正常。


实验后三台es服务的配置均加了
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"] 


只是ip,及超时时间略有不同，es2的超时时间设得最长。
es2的服务虽然正常了，但启动日志中会有个异常，如下：
[2015-07-22 21:43:29,012][WARN ][transport.netty          ] [Es_node_10_0_32_2] exception caught on transport layer [[id: 0x5c87285c]], closing connection
java.net.NoRouteToHostException: No route to host
at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)
at org.elasticsearch.common.netty.channel.socket.nio.NioClientBoss.connect(NioClientBoss.java:152)
at org.elasticsearch.common.netty.channel.socket.nio.NioClientBoss.processSelectedKeys(NioClientBoss.java:105)
at org.elasticsearch.common.netty.channel.socket.nio.NioClientBoss.process(NioClientBoss.java:79)
at org.elasticsearch.common.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:318)
at org.elasticsearch.common.netty.channel.socket.nio.NioClientBoss.run(NioClientBoss.java:42)
at org.elasticsearch.common.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
at org.elasticsearch.common.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
[2015-07-22 21:43:55,839][WARN ][discovery    
怀疑跟网络有关系，虽然不影响服务。

总结：

es服务启动后到发现集群的时间有点长，如果超时时间设得短则发现不了。这个原因还未知。只是通过修改设置让他尽可能能找到了集群了。

什么是“脑裂”现象？

由于某些节点的失效，部分节点的网络连接会断开，并形成一个与原集群一样名字的集群，这种情况称为集群脑裂（split-brain）现象。这个问题非常危险，因为两个新形成的集群会同时索引和修改集群的数据。

如何避免脑裂问题？

避免脑裂现象，用到的一个参数是：discovery.zen.minimum_master_nodes。这个参数决定了要选举一个Master需要多少个节点（最少候选节点数）。默认值是1。根据一般经验这个一般设置成 N/2 + 1，N是集群中节点的数量，例如一个有3个节点的集群，minimum_master_nodes 应该被设置成 3/2 + 1 = 2（向下取整）。

用到的另外一个参数是：discovery.zen.ping.timeout，等待ping响应的超时时间，默认值是3秒。如果网络缓慢或拥塞，建议略微调大这个值。这个参数不仅仅适应更高的网络延迟，也适用于在一个由于超负荷而响应缓慢的节点的情况。

如果您刚开始使用elasticsearch，建议搭建拥有3个节点的集群，这种方式可以把discovery.zen.minimum_master_nodes设置成2，这样就限制了发生脑裂现象的可能，且保持着高度的可用性：如果你设置了副本，在丢失一个节点的情况下，集群仍可运行。

真的高枕无忧了？

其实问题依然存在，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）产生影响，这些节点在任何节点上执行都不会被阻塞。

总结

脑裂问题依然是一个比较难以解决的问题，最终解决方案也是妥协的结果。这个问题也是分布式系统都会面临的问题。一下子想到了前几天看到的CAP理论，难道只有CP或者AP？
总体感觉ES还很年轻，但因为它的开箱即用、天生集群、自动容错、扩展性强等优点，还是选择它来做全文检索。