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

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

什么是脑裂问题
脑裂问题其实就是同一个集群的不同节点对于整个集群的状态有不同的理解，导致操作错乱，类似于精神分裂

怎么发现集群产生脑裂问题吧

1.Elasticsearch出现查询非常缓慢的情况

2.通过命令查看集群的状态

3.curl -XGET ‘http://localhost:9200/_cluster/health’

4.发现集群状态为red，且集群数量明显错误，再向不同的节点查询集群状态的时候，总体状态都是red，但是返回的集群数量却不太一样

5.正常情况下，访问每一个节点，对集群中的状态返回应该是一致的。不一致的信息表示集群中不同节点对master节点的选择出现了问题。导致集群不能正常工作

产生脑裂问题的原因

1.网络

2.由于某些节点之间的网络通信出现问题，导致一些节点认为master节点已经挂了，所以有重新选举了新的master节点，从而导致集群信息混乱，可以检查Ganglia集群监控，来查看是否是网络原因

3.节点负载过大：由于master节点与data节点都是混在一起的，有可能master节点的负载过大，导致对应的es实例停止响应，这时一部分节点会一位master节点已经挂掉从而重新选举，导致多master节点运行。同时由于data节点上ES进程占用的内存较大，较大规模的内存回收操作也能造成ES进程失去响应。所以，这个原因的可能性应该是最大的。

如何解决脑裂问题

对于网络问题，只能进行网络修复，在重启集群

对于负载的问题

一个直观的解决方案就是将master节点与data节点分离，准备几台机器加入集群中，这几台机器只能充当master节点，不可担任存储和搜索的角色

配置信息

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

使用例2的场景说明quorum是如何防止脑裂

假设集群中3个节点有一个节点与其他节点无法通信，

1、如果master是单独的节点，另外2个节点是master候选节点。那么此时单独的master节点因为没有指定数量的候选master node在自己当前所在的集群里。因此会取消当前的master角色，尝试重新选举（无法选举成功）

另外一个网络区域内的node因为无法连接到master，就会发起重新选举，有两个候选节点，满足quorum，成功选举出一个master。

2、如果master和一个node在一个网络区域（A），另一个node单独在一个网络区域（B）。

B区域只有一个node，因为连不上master，会尝试发起选举，但不满足quorum，无法选举

A区域master继续工作，当前网络也满足quorum，不发起选举。

discovery.zen.minimum_master_nodes除了在配置文件设置，也可以动态设置

PUT /_cluster/settings
{
   "persistent":{
      "discovery.zen.minimum_master_nodes":2
   }
}

 

如果脑裂问题已经发生该如何解决

1…当脑裂发生后，唯一的修复办法是解决这个问题并重启集群。 当elasticsearch集群启动时，会选出一个主节点（一般是启动的第一个节点被选为主）。由于索引的两份拷贝已经不一样了，elasticsearch会认为选出来的主保留的分片是“主拷贝”并将这份拷贝推送给集群中的其他节点。这很严重。让我们设想下你是用的是node客户端并且一个节点保留了索引中的正确数据。但如果是另外的一个节点先启动并被选为主，它会将一份过期的索引数据推送给另一个节点，覆盖它，导致丢失了有效数据。

2.所以怎么从脑裂中恢复？第一个建议是给所有数据重新索引。第二，如果脑裂发生了，要十分小心的重启你的集群。停掉所有节点并决定哪一个节点第一个启动。 如果需要，单独启动每个节点并分析它保存的数据。如果不是有效的，关掉它，并删除它数据目录的内容（删前先做个备份）。如果你找到了你想要保存数据的节点，启动它并且检查日志确保它被选为主节点。这之后你可以安全的启动你集群里的其他节点了。

 

转载：https://blog.csdn.net/ichen820/article/details/107414528、https://blog.csdn.net/zuodaoyong/article/details/104719508