ESTABLISHED 连接数

现象

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