How to Avoid Brain-Split for Elasticsearch Cluster

[LiangShang]

这一篇算是 HOW TO AVOID THE SPLIT-BRAIN PROBLEM IN ELASTICSEARCH 这篇文章的笔记吧。试着介绍一下 ES 的 Brain-Split 和 怎么来预防这个问题。

What is Brain Split?

首先考虑一下只有两个 ES Instance 的 Cluster。

Node1 是 Master，拥有 Primary Shard 0P。Node2 则是一个 Replica，拥有一个 Replica Shard 0R。

这个时候如果 Node1 和 Node2 之间没有了相应，（可能是因为网络异常，也可能是因为某个节点正在 Full-GC 而使得连接超时）。

那么两个节点的连接中断，但是它们都还活着，所以 Node1 是 Master 而 Node2 也认为自己是 Master（因为它相信只剩它自己了）。

这样的话集群就变成了两个节点都是 Master，而这就导致了 Inconsistency。比如一个 Index Request 发送给了 Node1，Node1 并不会把这个 request 发送给 Node2 而这就引起了两个节点的数据不一致。反之亦然。更为严重的是，这个错误对于 Client 来说是不可见的。因为 Index Request 和 Search Request 都不会出现错误。

How to Avoid Brain Split Problem

出现 Split Brain 问题的关键在于两个 Node 自己就可以将自己选举为 Master。因此我们需要规定只有集群里相应的节点大于一个阈值的时候才能进行选举。在config/elasticsearch.yml 文件里有一个参数 discovery.zen.minimum_master_nodes 可以用来设置那个阈值。通常这个值都设置为 N/2 + 1。N自然是集群里 ES 实例的个数。

另一个可以设置的参数是 discovery.zen.ping.timeout。也就是一个节点等待另一个无响应的节点多长时间才认为它是挂掉的。默认值是 3s。

Two Nodes Cluster?

设置 discovery.zen.minimum_master_nodes 就可以解决 Brain Split 的问题了，但是对于两个节点的 Cluster 来说意味着这个值要设为 2。在这个情形下当两个节点互相的连接中断时，Node1 和 Node2 都不会选举自己为 Master 而这就意味着 ES 的服务中断了。换言之，这可以解决 Brain Split 的问题但是却牺牲了可用性。因为当一个节点挂了时整个集群就停止工作了。

在这种情况之下，一个建议就是在集群里加入一个不存放数据的节点（By setting node.data to false ）。这个节点默认会被选举为 Master。此时就可以将 discovery.zen.minimum_master_nodes 设置为 2了。

Conclusion

这篇文章先介绍了为什么 ES 会出现 Brain Split，然后给出了一种解决方案，就是只有多数派存活时才会进行选举。最后讨论了当集群里只有两个节点时的解决方案。

原文还提到了即使是设置了那个阈值，也会有 Brain Split 存在。具体看这个 Issue。但是现在这个 Issue 已经被关掉了。我还要具体看看为什么。