Elasticsearch集群所谓脑裂的问题是怎样的
这篇文章将为大家详细讲解有关Elasticsearch集群所谓脑裂的问题是怎样的，文章内容质量较高，因此小编分享给大家做个参考，希望大家阅读完这篇文章后对相关知识有一定的了解。
站在用户的角度思考问题，与客户深入沟通，找到东昌府网站设计与东昌府网站推广的解决方案，凭借多年的经验，让设计与互联网技术结合，创造个性化、用户体验好的作品，建站类型包括：网站制作、成都网站制作、企业官网、英文网站、手机端网站、网站推广、主机域名、网页空间、企业邮箱。业务覆盖东昌府地区。
所谓脑裂问题（类似于精神分裂），就是同一个集群中的不同节点，对于集群的状态有了不一样的理解。
今天，Elasticsearch集群出现了查询极端缓慢的情况，通过以下命令查看集群状态：
curl -XGET 'es-1:9200/_cluster/health'
发现，集群的总体状态是red，本来9个节点的集群，在结果中只显示了4个；但是，将请求发向不同的节点之后，我却发现即使是总体状态是red的，但是可用的节点数量却不一致。
正 常情况下，集群中的所有的节点，应该对集群中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台服务器了，这点需要注意）。
以上的解决方法只能是减缓这种现象的发生，并不能从根本上杜绝。
关于Elasticsearch集群所谓脑裂的问题是怎样的就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
当前文章：Elasticsearch集群所谓脑裂的问题是怎样的
标题路径：http://6mz.cn/article/jipdpc.html