当前位置 博文首页 > 闫玉林的博客：Elasticsearch使用http接口更新数据失败：Elastic

最大化 缩小

    闫玉林的博客：Elasticsearch使用http接口更新数据失败：Elastic

    作者：[db:作者] 时间：2021-08-17 18:54

    现象

    • 前一天晚上重建了部分索引，大概几万条吧；第二天早上发现搜索有问题。
    • 使用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 red，Request 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的堆内存压力很大，大批量写入索引时，可能会报错
    • 还需要进一步测试和探究，暂时记下，未完待续
    cs
    上一篇：解析原生JS getComputedStyle
    下一篇：没有了