Elasticsearch使用http接口更新数据失败:ElasticSearchException: Socket Timeout for 120000ms

现象

  • 前一天晚上重建了部分索引,大概几万条吧;第二天早上发现搜索有问题。
  • 使用Bboss封装的http接口查询、更新、删除索引失败
  • 使用es的java api查询是可以的,更新删除没有测试
  • 报错:ElasticSearchException: Socket Timeout for 120000ms
  • 3个节点,一主二副,jvm参数配置为16G。
  • 索引分片为3,副本为2,{"settings":{"index":{"number_of_shards":3,"number_of_replicas":2}}}
  • 使用head插件查看,发现集群状态是GREEN,绿色健康状态
  • 使用kibana查看,发现集群是RED状态,显示插件错误,连接超时Elasticsearch plugin is redRequest timeout after 30000ms
  • 在网上搜了后,找到了官方论坛的一个帖子(链接),和我现象一样。
  • 确认是集群状态问题,为了解决问题,只有先重启了。3个节点逐个重启的,每个重启后,稍微等待2分钟,让集群分片同步,当集群变为GREEN时,重启下一个节点。
  • 重启第一个节点后,查询获取索引正常了,更新和删除索引仍然报错
  • 重启完3个节点后,所有操作恢复正常
  • 重启后某个索引数据量, 75G – 》 56G,感觉数据丢失了(惊恐
  • 随机找了一部分数据,搜索,发现数据都在,有点搞不清楚状况,难道是删除了一部分重复的没同步好的数据?(暂未明白原因
org.frameworkset.elasticsearch.ElasticSearchException: Socket Timeout for 120000ms.
	at org.frameworkset.elasticsearch.client.ElasticSearchRestClient.handleSocketTimeoutException(ElasticSearchRestClient.java:393)
	at org.frameworkset.elasticsearch.client.ElasticSearchRestClient._executeHttp(ElasticSearchRestClient.java:684)
	at org.frameworkset.elasticsearch.client.ElasticSearchRestClient.executeHttp(ElasticSearchRestClient.java:572)
	at org.frameworkset.elasticsearch.client.ElasticSearchRestClient.executeHttp(ElasticSearchRestClient.java:735)
	at org.frameworkset.elasticsearch.client.RestClientUtil.executeHttp(RestClientUtil.java:1546)
	at cn.lonsun.es.base.BbossUtil.bulkIndex(BbossUtil.java:469)
	at cn.lonsun.searchEngine.impl.IndexEsServiceImpl.batchCommit(IndexEsServiceImpl.java:838)
	at cn.lonsun.searchEngine.impl.IndexEsServiceImpl.deleteIndex(IndexEsServiceImpl.java:451)
	at cn.lonsun.content.internal.service.impl.BaseContentServiceImpl.delContent(BaseContentServiceImpl.java:1417)

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

问题处理

  • 之前出现过类似的问题,重启解决的
  • 本次为了快速解决掉问题,暂时先重启了。
  • 重启时需注意,要逐个节点重启,重启完一个后,集群状态变为健康GREEN,再重启下一个
  • 节点重启后,数据分片同步需要时间,耐心等一下,一般几分钟内就好
  • 可以结合es日志和head插件确认集群是否恢复健康。[2020-04-19T10:47:39,169][INFO ][o.e.c.r.DelayedAllocationService] [node-1-master-8-9200] scheduling reroute for delayed shards in [0s] (16 delayed shards)

原因探究

  • 之前也是批量插入索引后,连接超时
  • 综合遇到的现象,是在插入文本量比较大的索引(一条数据可能有20K或更多)时,大批量插入时触发这个问题
  • 出问题的索引index,相对比其他索引,数据量较大(出问题的节点,数据量75G,其他的也就10G左右)
  • 之前搜索问题原因,网上说是大批量提交索引更新请求时,es服务器并不能很快的处理完,当数据队列占用完后,来不及处理,就会触发超时
  • 和es的jvm配置有关,一开始设置2G内存,后来改为16G,问题得到了解决。但是现在服务运行有半年了,数据量越来越多,再次触发了这个问题。(在jvm.option修改)在这里插入图片描述
  • 本次搜索结果,是说分片不合理,链接:Elasticsearch集群分片设置,当分片和索引很多时,es的堆内存压力很大,大批量写入索引时,可能会报错
  • 还需要进一步测试和探究,暂时记下,未完待续
  • 2
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 2
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

坚持是一种态度

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值