如何防止ElasticSearch集群出现脑裂现象

如何防止ElasticSearch集群出现脑裂现象

什么是“脑裂”现象?

由于某些节点的失效,部分节点的网络连接会断开,并形成一个与原集群一样名字的集群,这种情况称为集群脑裂(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还很年轻,但因为它的开箱即用、天生集群、自动容错、扩展性强等优点,还是选择它来做全文检索。

参考资料

  • HOW TO AVOID THE SPLIT-BRAIN PROBLEM IN ELASTICSEARCH
  • minimum_master_nodes does not prevent split-brain if splits are intersecting #2488
  • zen discovery
  • 《Mastering Elasticsearch(中文版)》

你可能感兴趣的:(Elasticsearch,大数据)