es脑裂问题

一个正常es集群中只有一个主节点，主节点负责管理整个集群，集群的所有节点都会选择同一个节点作为主节点所以无论访问那个节点都可以查看集群的状态信息。 而脑裂问题的出现就是因为从节点在选择主节点上出现分歧导致一个集群出现多个主节点从而使集群分裂，使得集群处于异常状态。

原因：

1：网络原因

        内网一般不会出现此问题，可以监控内网流量状态。外网的网络出现问题的可能性大些。

2：节点负载

         主节点即负责管理集群又要存储数据，当访问量大时可能会导致es实例反应不过来而停止响应，此时其他节点在向主节点发送消息时得不到主节点的响应就会认为主节点挂了，从而重新选择主节点。

3：回收内存

         大规模回收内存时也会导致es集群失去响应。

所以内网负载的可能性大，外网网络的可能性大。

再来看看ES（Elastic Search）主动选举机制：

elasticsearch集群一旦建立起来以后，会选举出一个master，其他都为slave节点。但是具体 *** 作的时候，每个节点都提供写和读的 *** 作。就是说，你不论往哪个节点中做写 *** 作，这个数据也会分配到集群上的所有节点中。

这里有某个节点挂掉的情况，如果是slave节点挂掉了，那么首先关心，数据会不会丢呢？不会。如果你开启了replicate，那么这个数据一定在别的机器上是有备份的。别的节点上的备份分片会自动升格为这份分片数据的主分片。这里要注意的是这里会有一小段时间的yellow状态时间。

如果是主节点挂掉怎么办呢？当从节点们发现和主节点连接不上了，那么他们会自己决定再选举出一个节点为主节点。但是这里有个脑裂的问题，假设有5台机器，3台在一个机房，2台在另一个机房，当两个机房之间的联系断了之后，每个机房的节点会自己聚会，推举出一个主节点。这个时候就有两个主节点存在了，当机房之间的联系恢复了之后，这个时候就会出现数据冲突了。

预防方案：

1：角色分离

         在es集群中配置2到3个主节点并且让它们只负责管理不负责存储，从节点只负责存储。另外从节点禁用自动发现机制并为其指定主节点，在elasticsearch.yml文件中。

主节点：node.master =true   node.data=false

从节点：node.master =false   node.data=ture

discovery.zen.ping.multicast.enabled:false

discovery.zen.ping.unicast.hosts:["host1", "host2:port"]

2：参数配置

discovery.zen.ping_timeout:3

       此参数指定从节点访问主节点后如果3秒之内没有回复则默认主节点挂了，我们可以适当的把它改大，这样可以减少出现脑裂的概率。

       discovery.zen.minimum_master_nodes:1

       该参数的意思是，当具备成为主节点的从节点的个数满足这个数字且都认为主节点挂了则会进行选举产生新的主节点。

       例如：es集群有三个从节点有资格成为主节点，这时这三个节点都认为主节点挂了则会进行选举，此时如果这个参数的值是4则不会进行选举。

       我们可以适当的把这个值改大，减少出现脑裂的概率，官方给出的建议是(n/2)+1,n为有资格成为主节点的节点数node.master=true。

问题如图片类似，后台启动ES集群，由三个节点组成，集群健康值为 yellow，节点只有主分片，副本状态为：Unassigned

2. 原因：

在ES磁盘分配分片控制策略中，为了保护数据节点的安全，ES对磁盘进行了限额，并会定时检查各节点数据目录的使用情况：

cluster.info.update.interval // 默认30秒

在达到

cluster.routing.allocation.disk.watermark.low // 默认85%

时，新索引分片就不会分配到这个节点上了。在达到

cluster.routing.allocation.disk.watermark.high // 默认 90%

时，就会触发该节点现存分片的数据均衡，把数据挪到其他节点上去。

通过shell 客户端执行 df -h ,查询到es集群所在的路径 /home/app 的磁盘使用率 Use%值为 86%，超过了最低值 85%，导致重启后，副本索引分片不会分配到es集群中的节点上。

3. 如何修改：

方案一：

删除es集群所在路径不必要大文件，如旧的日志文件，临时文件等，使 Use% 值小于 85%。

方案二：

修改 ES分片控制策略，提高cluster.routing.allocation.disk.watermark.low的值，该值大于当前 ES 集群所在路径 %Use的值。

修改示例：

curl -XPUT localhost:9200/_cluster/settings -d '{

    "transient": {

        "cluster.routing.allocation.disk.watermark.low": "90%",

        "cluster.routing.allocation.disk.watermark.high": "95%"

    }

}'

或使用postman

4. 参考：

elasticsearch问题解决之分片副本Unassigned: https://www.cnblogs.com/carryLess/p/9452000.html

《kibana中文指南》中ElasticSearch- 架构原理- shard的allocate控制 章节。