Elasticsearch集群的脑裂问题

标签: elasticsearch 集群 问题 | 发表时间:2017-06-12 09:34 | 作者:hunan84229247
出处:http://www.iteye.com
所谓脑裂问题(类似于精神分裂),就是同一个集群中的不同节点,对于集群的状态有了不一样的理解。


今天,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节点,不担任存储和搜索的角色,故它们是相对轻量级的进程。可以通过以下配置来限制其角色:

[plain] view plain copy
node.master: true 
node.data: false 

当然,其它的节点就不能再担任master了,把上面的配置反过来即可。这样就做到了将master节点与data节点分离。当然,为了使新加入的节点快速确定master位置,可以将data节点的默认的master发现方式有multicast修改为unicast:

[plain] view plain copy
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台服务器了,这点需要注意)。

已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [elasticsearch 集群 问题] 推荐:

Elasticsearch集群的脑裂问题

- - 互联网 - ITeye博客
所谓脑裂问题(类似于精神分裂),就是同一个集群中的不同节点,对于集群的状态有了不一样的理解. 今天,Elasticsearch集群出现了查询极端缓慢的情况,通过以下命令查看集群状态:. 发现,集群的总体状态是red,本来9个节点的集群,在结果中只显示了4个;但是,将请求发向不同的节点之后,我却发现即使是总体状态是red的,但是可用的节点数量却不一致.

elasticsearch集群搭建

- - zzm
之前对于CDN的日志处理模型是从 . logstash agent==>>redis==>>logstash index==>>elasticsearch==>>kibana3,对于elasticsearch集群搭建,可以把索引进行分片存储,一个索引可以分成若干个片,分别存储到集群里面,而对于集群里面的负载均衡,副本分配,索引动态均衡(根据节点的增加或者减少)都是elasticsearch自己内部完成的,一有情况就会重新进行分配.

Elasticsearch集群入门

- - 编程语言 - ITeye博客
欢迎来到Elasticsearch的奇妙世界,它是优秀的全文检索和分析引擎. 不管你对Elasticsearch和全文检索有没有经验,都不要紧. 我们希望你可以通过这本书,学习并扩展Elasticsearch的知识. 由于这本书也是为初学者准备的,我们决定先简单介绍一般性的全文检索概念,接着再简要概述Elasticsearch.

elasticsearch 1.x集群优化

- - ITeye博客
欢迎发送邮件至 donlianli@126.com. 本博文为 Elasticsearch Server2nd的部分第7章部分章节的翻译,版权归原作者. 设置Filter cache. 缓存是提高性能的很重要的手段,es中的filter cache能够把搜索时的filter条件的结果进行缓存,当进行相同的filter搜索时(query不同,filter条件相同),es能够很快的返回结果.

elasticsearch集群监控工具bigdesk

- - zzm
bigdesk是elasticsearch的一个集群监控工具,可以通过它来查看es集群的各种状态,如:cpu、内存使用情况,索引数据、搜索情况,http连接数等. 项目git地址:  https://github.com/lukas-vlcek/bigdesk. 和head一样,它也是个独立的网页程序,使用方式和head一样.

ElasticSearch-2.0.0集群安装配置与API使用实践

- - 简单之美
ElasticSearch是基于全文搜索引擎库Lucene构建的分布式搜索引擎,我们可以直接使用ElasticSearch实现分布式搜索系统的搭建与使用,都知道,Lucene只是一个搜索框架,它提供了搜索引擎操作的基本API,如果要实现一个能够使用的搜索引擎系统,还需要自己基于Lucene的API去实现,工作量很大,而且还需要很好地掌握Lucene的底层实现原理.

实例展示elasticsearch集群生态,分片以及水平扩展. - 苏若年

- - 博客园_首页
  elasticsearch用于构建高可用和可扩展的系统. 扩展的方式可以是购买更好的服务器(纵向扩展)或者购买更多的服务器(横向扩展),Elasticsearch能从更强大的硬件中获得更好的性能,但是纵向扩展也有一定的局限性. 真正的扩展应该是横向的,它通过增加节点来传播负载和增加可靠性. 对于大多数数据库而言,横向扩展意味着你的程序将做非常大的改动来利用这些新添加的设备.

配置高性能 ElasticSearch 搜索引擎集群的9个小贴士

- - ITeye资讯频道
Loggly服务底层的很多核心功能都使用了ElasticSearch作为搜索引擎. 就像Jon Gifford(译者注:Loggly博客作者之一)在他近期关于“ElasticSearch vs Solr”的文章中所述,日志管理在搜索技术方面产生一些粗暴的需求,坚持下来以后,它必须能够:. 在超大规模数据集上可靠地进行准实时索引 – 在我们的案例中,每秒有超过100,000个日志事件与此同时,在该索引上可靠高效地处理超大量的搜索请求.

Redis集群“倾斜”问题

- - 今天
对分布式存储系统的架构和运维管理,如何保证每个Node的数据存储容量和请求量尽量均衡,是非常重要的. 本文介绍Redis大集群运维过程中,常见导致数据和请求量“倾斜”的场景,及规避措施. Redis数据容量或请求量严重”倾斜”的影响. 以下从运维的角度解释,Redis数十节点的集群,出现数据容量和请求量倾斜情况下,存在的一些痛点:.

使用elasticsearch遇到的一些问题以及解决方法(不断更新)

- - 行业应用 - ITeye博客
     因为gc时会使jvm停止工作,如果某个节点gc时间过长,master ping3次(zen discovery默认ping失败重试3次)不通后就会把该节点剔除出集群,从而导致索引进行重新分配. (1)优化gc,减少gc时间. (2)调大zen discovery的重试次数(es参数:ping_retries)和超时时间(es参数:ping_timeout).