Elasticsearch脑裂问题详细分析以及解决方案

什么是脑裂问题

如果服务器网络中断或者服务器宏机，那么集群会有可能被划分为两个部分，各自与自己的master来管理，这就是脑裂（脑裂问题其实就是同一个集群的不同节点对于整个集群的状态有不同的理解，导致操作错乱）

网络
由于某些节点之间的网络通信出现问题，导致一些节点认为master节点已经挂了，所以又重新选举了新的master节点，从而导致集群信息混乱
节点负载过大：由于master节点与data节点都是混在一起的，有可能master节点的负载过大，导致对应的es实例停止响应，这时一部分节点会一位master节点已经挂掉从而重新选举，导致多master节点运行。同时由于data节点上ES进程占用的内存较大，较大规模的内存回收操作也能造成ES进程失去响应。所以，这个原因的可能性应该是最大的。

对于网络问题，只能进行网络修复，在重启集群
对于负载的问题，一个直观的解决方案就是将master节点与data节点分离，准备几台机器加入集群中，这几台机器只能充当master节点，不可担任存储和搜索的角色

配置信息如下：

1
2
3
4
5
6


# 主节点
node.master: true
node.data: false
# 其他节点  只能充当data不能充当master
node.master: false
node.data: true

还有两个参数的修改可以减少脑裂问题的出现 1.discovery.zen.ping_timeout(默认值是3秒)：默认情况下，一个节点会认为，如果master节点在3秒之内没有应答，那么这个节点就是死掉了，而增加这个值，会增加节点等待响应的时间，从一定程度上会减少误判。

2.discovery.zen.minimum_master_nodes(默认是1)：这个参数控制的是，一个节点需要看到的具有master节点资格的最小数量，然后才能在集群中做操作。官方的推荐值是(N/2)+1，其中N是具有master资格的节点的数量

discovery.zen.minimum_master_nodes对集群的稳定性至关重要，防止脑裂的出现。

discovery.zen.minimum_master_nodes的作用是只有足够的master候选节点时，才可以选举出一个master。该参数必须设置为集群中master候选节点的quorum数量。

quorum的算法=master候选节点数量/2+1

举例：

1、如果有10个节点，都是data node，也是master的候选节点。则quorum=10/2+1=6

2、如果有3个master候选节点，100个数据节点。则quorum=3/2+1=2

3、如果有2个节点，都是data node，也是master的候选节点。则quorum=2/2+1=2(有问题)

如果其中一个节点挂了，那么master的候选节点只有一个，无法满足quorum数量。即无法选举出master。此时只能将quorum设置成1，但是设置为1有可能出现脑裂。

总结：一般es集群的节点至少要有3个，quorum设置为2

当脑裂发生后，唯一的修复办法是解决这个问题并重启集群。当elasticsearch集群启动时，会选出一个主节点(一般是启动的第一个节点被选为主)。由于索引的两份拷贝已经不一样了，elasticsearch会认为选出来的主保留的分片是“主拷贝”并将这份拷贝推送给集群中的其他节点。这很严重。让我们设想下你是用的是node客户端并且一个节点保留了索引中的正确数据。但如果是另外的一个节点先启动并被选为主，它会将一份过期的索引数据推送给另一个节点，覆盖它，导致丢失了有效数据。
所以怎么从脑裂中恢复？第一个建议是给所有数据重新索引。第二，如果脑裂发生了，要十分小心的重启你的集群。停掉所有节点并决定哪一个节点第一个启动。如果需要，单独启动每个节点并分析它保存的数据。如果不是有效的，关掉它，并删除它数据目录的内容(删前先做个备份)。如果你找到了你想要保存数据的节点，启动它并且检查日志确保它被选为主节点。这之后你可以安全的启动你集群里的其他节点了。

老版本可能出现脑裂的问题。

在最新版7.x中，这一块的内容已经交个ES自身管理，discovery.zen.minimum_master_nodes属性已经被移除。这样就避免了脑裂的问题，选举也非常快

原文链接：https://blog.csdn.net/m0_53121042/article/details/111466418