elasticsearch 宕机1台 会有20分钟不可访问

Elasticsearch | 作者 taoyantu | 发布于2018年12月27日 | 阅读数:472

向各位请教一下,我们有9台物理机,27个节点的es服务器,总数据量大于10来个T,每天数据大概1个T,当有1台物理机宕机的情况下,集群是黄色,但是会有20来分钟,运行非常慢,请求会超时。 我理解,当时集群会做两个动作,1个是副本的恢复,1个是数据的重平衡,有什么办法解决这个问题吗?能不能调整他降低他恢复的速度?不要1台宕机就影响一段时间数据无法查询和写入
已邀请:

kennywu76 - wood@Ctrip

赞同来自: rockybean ridethewind

如集群正常工作的情况下,cpu/磁盘io已经接近饱和了,那么数据恢复的确可能影响到读写的吞吐量,这个时候只能是控制recovery的速率(集群有个设置indices.recovery.max_bytes_per_sec) 或者按照Rockybean的方法,延缓recovery触发的时机,等待故障节点恢复重新加入集群以后,从本地恢复大部分数据,尽量减小recovery带来的影响。 如果这些都不解决问题,就只能是扩容硬件了。
 
不过你有10台物理机,数据总量只有10TB左右,一台机器跑一个ES实例性能会更好。 多实例部署,如果heap划分又很大,通常会造成heap空间过剩而系统缓存不够的尴尬情况,性能相反会大幅降低。一般来说跑多实例的目的是为了在一个节点上存储尽量多的数据,响应的代价是牺牲一些读写性能。
 
最后一点就是要注意控制集群的index/shard的数量,如果shard数量非常多(上万),出现节点故障的情况下,master节点可能会不堪重负。 如果你没有单独设立master,而是混入了data node,那么也是有可能对读写产生较大的影响。
 
 

rockybean - Elastic Certified Engineer, ElasticStack Fans,公众号:ElasticTalk

赞同来自: kennywu76

你现在1台物理机有3个节点,所以实际是一次3个 es 节点挂了,那么实际需要重新分配1TB 左右的数据,这个过程是会影响集群性能的。
有一个解决方法是延迟集群再分配分片的时间,在这个时间到来之前将停掉的节点启动起来,可以节省大量分片重分配的时间。
https://www.elastic.co/guide/e ... .html
 
PUT _all/_settings
{
"settings": {
"index.unassigned.node_left.delayed_timeout": "5m"
}
}
这个值你可以设的大一些,比如一天 1d,这样有充分的时间来恢复节点

laoyang360 - [死磕Elasitcsearch]知识星球地址:http://t.cn/RmwM3N9;微信公众号:铭毅天下; 博客:https://elastic.blog.csdn.net

赞同来自:

有办法的,
步骤1 排除停用节点

您可以通过告知群集将其从分配中排除来停用节点。

PUT _cluster/settings
{
"transient" : {
"cluster.routing.allocation.exclude._ip" : "10.0.0.1"
}
}

这将导致Elasticsearch将该节点上的分片分配给其余节点,而不会将群集状态更改为黄色或红色(即使您的副本数设置为0)。
重新分配所有分片后,您可以关闭节点并执行您需要执行的任何操作。 完成后,,Elasticsearch将再剩余节点上再次重新平衡分片。

步骤2 检查集群健康状态

curl -XGET ‘http://ES_SERVER:9200/_cluster/health?pretty
如果没有节点relocating,则排除节点已经被安全剔除,可以考虑关闭节点。

步骤3 判定数据是否还存在

查看节点上是否还有文档存在。
curl -XGET ‘http://ES_SERVER:9200/_nodes/N ... retty
上述三步,能保证节点稳妥删除。

zqc0512 - andy zhou

赞同来自:

1.PUT _all/_settings { "settings": { "index.unassigned.node_left.delayed_timeout": "5m" } }  5m改大,修改成你能够重新启动节点的时间。
2.设置剔除节点,需要注意的时,当节点挂的时候,你能够及时发现,搞个监控吧。
 
 

要回复问题请先登录注册