一个正常es集群中只有一个主节点，主节点负责管理整个集群，集群的所有节点都会选择同一个节点作为主节点；所以无论访问那个节点都可以查看集群的状态信息。 而脑裂问题的出现就是因为从节点在选择主节点上出现分歧导致一个集群出现多个主节点从而使集群分裂，使得集群处于异常状态
这样的脑裂状态直接让节点失去了集群的正确状态，导致集群不能正常工作。
可能导致的原因：
1. 网络：由于是内网通信，网络通信问题造成某些节点认为master死掉;
当出现网络风暴，IO大面积阻塞、爬虫等现象的时候，就会造成master宕机
2. 节点负载：**由于master节点与data节点都是混合在一起的**，所以当工作节点的负载较大（确实也较大）时，导致对应的ES实例停止响应，而这台服务器如果正充当着master节点的身份，那么一部分节点就会认为这个master节点失效了，故重新选举新的节点，这时就出现了脑裂；同时由于data节点上ES进程占用的内存较大，较大规模的内存回收操作也能造成ES进程失去响应。所以，这个原因的可能性应该是最大的。
应对问题的办法： 1.
对应于上面的分析，推测出原因应该是由于节点负载导致了master进程停止响应，继而导致了部分节点对于master的选择出现了分歧。为此，**一个直观的解决方案便是将master节点与data节点分离**。为此，我们添加了三台服务器进入ES集群，不过它们的角色只是master节点，不担任存储和搜索的角色，故它们是相对轻量级的进程。可以通过以下配置来限制其角色：
node.master: true （指定该节点是否有资格被选举成为master，默认是true，es是默认集群中的第一台机器为master，如果这台机挂了就会重新选举master。）
node.data: false (指定该节点是否存储索引数据，默认为true。)
当然，其它的节点就不能再担任master了，把上面的配置反过来即可。这样就做到了将master节点与data节点分离。
还有两个直观的参数可以减缓脑裂问题的出现：
1. 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台服务器了，这点需要注意**）
以上的解决方法只能是减缓这种现象的发生，并没有从根本上杜绝。
如果发生了脑裂，如何解决? 当脑裂发生后，唯一的修复办法是解决这个问题并重启集群。当elasticsearch集群启动时，会选出一个主节点（一般是启动的第一个节点被选为主）。由于索引的两份拷贝已经不一样了，elasticsearch会认为选出来的主保留的分片是“主拷贝”并将这份拷贝推送给集群中的其他节点。这很严重。让我们设想下你是用的是node客户端并且一个节点保留了索引中的正确数据。但如果是另外的一个节点先启动并被选为主，它会将一份过期的索引数据推送给另一个节点，覆盖它，导致丢失了有效数据。
总结 所以怎么从脑裂中恢复？第一个建议是给所有数据重新索引。第二，如果脑裂发生了，要十分小心的重启你的集群。停掉所有节点并决定哪一个节点第一个启动。 如果需要，单独启动每个节点并分析它保存的数据。如果不是有效的，关掉它，并删除它数据目录的内容（删前先做个备份）。如果你找到了你想要保存数据的节点，启动它并且检查日志确保它被选为主节点。这之后你可以安全的启动你集群里的其他节点了。