集群脑裂是什么？

　　所谓脑裂问题（类似于精神分裂），就是同一个集群中的不同节点，对于集群的状态有了不一样的理解。

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

　　今天，Elasticsearch集群出现了查询极端缓慢的情况，通过以下命令查看集群状态：

　　curl -XGET 'http://master:9200/_cluster/health'

　　　　或者

　　curl -XGET 'http://localhost:9200/_cluster/health'

　　发现，集群的总体状态是red，本来9个节点的集群，在结果中只显示了4个；但是，将请求发向不同的节点之后，我却发现即使是总体状态是red的，但是可用的节点数量却不一致。

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

ES集群脑裂可能导致的原因：
1. 网络： 由于是内网通信， 网络通信问题造成某些节点认为 master 死掉， 而另选 master的可能性较小； 进而检查 Ganglia 集群监控， 也没有发现异常的内网流量， 故此原因可以排除。

 　　内网一般不会出现es集群的脑裂问题，可以监控内网流量状态。外网的网络出现问题的可能性大些。

　　2. 节点负载： 由于 master 节点与 data 节点都是混合在一起的， 所以当工作节点的负载较大（ 确实也较大） 时， 导致对应的 ES 实例停止响应， 而这台服务器如果正充当着 master节点的身份， 那么一部分节点就会认为这个 master 节点失效了， 故重新选举新的节点， 这时就出现了脑裂； 同时由于 data 节点上 ES 进程占用的内存较大， 较大规模的内存回收操作也能造成 ES 进程失去响应。 所以， 这个原因的可能性应该是最大的。

 　　3、回收内存

　　由于data节点上es进程占用的内存较大，较大规模的内存回收操作也能造成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 秒之内没有应答， 那么这个节点就是死掉了， 而增加这个值， 会增加节点等待响应的时间， 从一定程度上会减少误判。

　　3、discovery.zen.minimum_master_nodes（ 默认是 1） ： 这个参数控制的是， 一个节点需要看到的具有 master 节点资格的最小数量， 然后才能在集群中做操作。 官方的推荐值是(N/2)+1， 其中 N 是具有 master 资格的节点的数量（ 我们的情况是 3， 因此这个参数设置为2， 但对于只有 2 个节点的情况， 设置为 2 就有些问题了， 一个节点 DOWN 掉后， 你肯定连不上 2 台服务器了， 这点需要注意） 。

　　以上的解决方法只能是减缓这种现象的发生， 并没有从根本上杜绝。

如果发生了脑裂， 如何解决?
当脑裂发生后， 唯一的修复办法是解决这个问题并重启集群。 这儿有点复杂和可怕。 当elasticsearch 集群启动时， 会选出一个主节点（ 一般是启动的第一个节点被选为主） 。 由于索引的两份拷贝已经不一样了， elasticsearch 会认为选出来的主保留的分片是“主拷贝”并将这份拷贝推送给集群中的其他节点。 这很严重。 让我们设想下你是用的是 node 客户端并且一个节点保留了索引中的正确数据。 但如果是另外的一个节点先启动并被选为主， 它会将一份过期的索引数据推送给另一个节点， 覆盖它， 导致丢失了有效数据。

总结
所以怎么从脑裂中恢复？

　　 第一个建议是给所有数据重新索引。

　　第二， 如果脑裂发生了， 要十分小心的重启你的集群。 停掉所有节点并决定哪一个节点第一个启动。 如果需要， 单独启动每个节点并分析它保存的数据。 如果不是有效的， 关掉它， 并删除它数据目录的内容（ 删前先做个备份） 。 如果你找到了你想要保存数据的节点， 启动它并且检查日志确保它被选为主节点。 这之后你可以安全的启动你集群里的其他节点了。

本文转自大数据躺过的坑博客园博客，原文链接：http://www.cnblogs.com/zlslch/p/6477312.html，如需转载请自行联系原作者