Elasticsearch使用过程中的问题总结

Myth丶恋晨 2022-06-02 22:12 279阅读 0赞

#### 1、es脑裂问题 ####

由于某些节点的失效，部分节点的网络连接会断开，并形成一个与原集群一样名字的集群，这种情况成为集群脑裂（split-brain）现象。这个问题非常危险，因为两个新形成的集群会同时索引和修改集群的数据。

正常情况下，集群中的所有的节点，应该对集群中master的选择是一致的，这样获得的状态信息也应该是一致的，不一致的状态信息，说明不同的节点对master节点的选择出现了异常——也就是所谓的脑裂问题。这样的脑裂状态直接让节点失去了集群的正确状态，导致集群不能正常工作。  
**ES集群脑裂导致的原因：**  
　　1. 网络： 由于是内网通信， 网络通信问题造成某些节点认为 master 死掉， 而另选 master的可能性较小； 进而检查 Ganglia 集群监控， 也没有发现异常的内网流量， 故此原因可以排除。  
　　 内网一般不会出现es集群的脑裂问题，可以监控内网流量状态。外网的网络出现问题的可能性大些。  
　　2. 节点负载： 由于 master 节点与 data 节点都是混合在一起的， 所以当工作节点的负载较大（ 确实也较大） 时， 导致对应的 ES 实例停止响应， 而这台服务器如果正充当着 master节点的身份， 那么一部分节点就会认为这个 master 节点失效了， 故重新选举新的节点， 这时就出现了脑裂； 同时由于 data 节点上 ES 进程占用的内存较大， 较大规模的内存回收操作也能造成 ES 进程失去响应。 所以， 这个原因的可能性应该是最大的。  
　　3、回收内存  
　　由于data节点上es进程占用的内存较大，较大规模的内存回收操作也能造成es进程失去响应。  
解决方案：  
之前的博客有描述，master节点和data节点分离。

#### 2、 集群中出现大量shard unassiged问题，如何修复？ ####

当集群重启过程中如果出现unassiged的分片，如何快速修复,下面两个链接都是很好的解决方案  
[https://www.datadoghq.com/blog/elasticsearch-unassigned-shards/\#reason-1-shard-allocation-is-purposefully-delayed][https_www.datadoghq.com_blog_elasticsearch-unassigned-shards_reason-1-shard-allocation-is-purposefully-delayed]

[http://www.wklken.me/posts/2015/05/23/elasticsearch-issues.html][http_www.wklken.me_posts_2015_05_23_elasticsearch-issues.html]

![SouthEast][]  
![SouthEast 1][]

curl -XPUT 'localhost:9200/<INDEX_NAME>/_settings' -d ' { "settings": { "index.unassigned.node_left.delayed_timeout": "30s" } }'

#### 3、节点负载过高，GC频繁？ ####

首先判断是否CPU过高或部分IO等待导致，并排除其他组件的影响，GC的问题可以升级G1回收器（JDK1.8 40版本以上），同时需要考虑降低副本数到0或1、部分增加超时时间来降低影响。一般来说，ES配置可优化的点很少，更多的是使用的问题。当使用X-pack插件时要注意，每台机器都需要装该插件。

#### 4、 ES如何安全重启—–滚动重启 ####

参考官网地址：  
[https://www.elastic.co/guide/cn/elasticsearch/guide/current/\_rolling\_restarts.html\#\_rolling\_restarts][https_www.elastic.co_guide_cn_elasticsearch_guide_current_rolling_restarts.html_rolling_restarts]

总有一天你会需要做一次集群的滚动重启——保持集群在线和可操作，但是逐一把节点下线。

常见的原因：Elasticsearch 版本升级，或者服务器自身的一些维护操作（比如操作系统升级或者硬件相关）。不管哪种情况，都要有一种特别的方法来完成一次滚动重启。

正常情况下，Elasticsearch 希望你的数据被完全的复制和均衡的分布。如果你手动关闭了一个节点，集群会立刻发现节点的丢失并开始再平衡。如果节点的维护是短期工作的话，这一点就很烦人了，因为大型分片的再平衡需要花费相当的时间（想想尝试复制 1TB 的数据——即便在高速网络上也是不一般的事情了）。

我们需要的是，告诉 Elasticsearch 推迟再平衡，因为对外部因子影响下的集群状态，我们自己更了解。操作流程如下：

*  1.可能的话，停止索引新的数据。虽然不是每次都能真的做到，但是这一步可以帮助提高恢复速度。
 *  2.禁止分片分配。这一步阻止 Elasticsearch 再平衡缺失的分片，直到你告诉它可以进行了。如果你知道维护窗口会很短，这个主意棒极了。你可以像下面这样禁止分配：

PUT /_cluster/settings
    {
        "transient" : {
            "cluster.routing.allocation.enable" : "none"
        }
    }

*  3.关闭单个节点。
 *  4.执行维护/升级。
 *  5.重启节点，然后确认它加入到集群了。
 *  6.用如下命令重启分片分配

PUT /_cluster/settings
    {
        "transient" : {
            "cluster.routing.allocation.enable" : "all"
        }
    }

分片再平衡会花一些时间。一直等到集群变成 绿色 状态后再继续。  
\- 7.重复第 2 到 6 步操作剩余节点。  
\- 8.到这步你可以安全的恢复索引了（如果你之前停止了的话），不过等待集群完全均衡后再恢复索引，也会有助于提高处理速度.

**主要几个需要注意的点：**  
1.不要通过kill -9来停止服务  
2.滚动重启时需要等待该节点加入集群，加入集群后再开启自动分配分片，直到分片分配结束.  
3.重启各台机器前需要先关闭自动分配分片

[https_www.datadoghq.com_blog_elasticsearch-unassigned-shards_reason-1-shard-allocation-is-purposefully-delayed]: https://www.datadoghq.com/blog/elasticsearch-unassigned-shards/#reason-1-shard-allocation-is-purposefully-delayed
[http_www.wklken.me_posts_2015_05_23_elasticsearch-issues.html]: http://www.wklken.me/posts/2015/05/23/elasticsearch-issues.html
[SouthEast]: /images/20220603/83ce571df67a4a289dcfe17a69480165.png
[SouthEast 1]: /images/20220603/e3c8a47c220747eaa89a013b07d0764c.png
[https_www.elastic.co_guide_cn_elasticsearch_guide_current_rolling_restarts.html_rolling_restarts]: https://www.elastic.co/guide/cn/elasticsearch/guide/current/_rolling_restarts.html#_rolling_restarts