如何防止ElasticSearch集群出现脑裂现象（转）
原文：http://xingxiudong.com/2015/01/05/resolve-elasticsearch-split-brain/
什么是“脑裂”现象？
由于某些节点的失效，部分节点的网络连接会断开，并形成一个与原集群一样名字的集群，这种情况称为集群脑裂（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还很年轻，但因为它的开箱即用、天生集群、自动容错、扩展性强等优点，还是选择它来做全文检索。
参考资料
最新文章
- 【原】常用的javascript设计模式
- FTP命令
- OpenGL学习笔记0——安装库
- 用消息机制解耦Activity跳转
- Delphi函数指针
- O_NONBLOCK on regular file
- LoadRunner场景参数文件部分参数说明（我在某银行的整理）
- 读书笔记——Windows环境下32位汇编语言程序设计（13）关于EXCEPTION_DEBUG_INFO结构体
- DataTable排序的一般方法
- vector 与map的下标操作
- swift 点击button改变其内填充图片,达到选中的效果
- Linux查看网络即时网速
- Protobuf-net基础
- openCV之头文件分析
- 记一次list循环删除元素的突发事件！
- redis参数配置说明
- 微信小程序-布局
- 基于SpringBoot从零构建博客网站 - 整合lombok和mybatis-plus提高开发效率
- spring事物与传播行为
- LoadRunner录制脚本时没有响应——无法启动浏览器问题总结