线上三台集群部署的集群状态为red,持续了好几天,下面分析一下问题根源以及解决思路。
确定集群状态curl http://*:9200/_cluster/health?pretty
- 有两个未分配的分片,初步怀疑是由于分片分配不成功,导致索引异常,下一步查找异常索引确认问题
确定异常索引
# 查看所有索引状态
curl -XGET "http://*:9200/_cat/indices?pretty"
# 查看异常索引状态
curl -XGET "http://*:9200/_cat/indices?v&health=red"
- 找到异常索引
查看异常索引分片分配状态curl -XGET "http://*:9200/_cat/shards/some_index_name?v"
查看分片分配不成功的原因curl -XGET "http://*:9200/_cat/shards/some_index_name?v&h=n,index,shard,prirep,state,sto,sc,unassigned.reason,unassigned.details"
- 片分配失败原因:获取共享锁超时
ALLOCATION_FAILED failed shard on node [TFLMMP_nS6iPUx_C098SbA]: failed to create shard, failure IOException[failed to obtain in-memory shard lock]; nested: ShardLockObtainFailedException[[some_index_name][0]: obtaining shard lock timed out after 5000ms]
重新分配失败的分片curl -XPOST "http://*:9200/_cluster/reroute?retry_failed=true"
- 重新分配失败的分片后,集群状态恢复green
问题避免
- 修改ES设置,调整ES进行分片分配的重试次数(默认为5次)
curl -XPUT "http://*:9200/some_index_name/_settings" -d'
{
"index": {
"allocation": {
"max_retries": 20
}
}
}'
- 可进一步查看ES的CPU和内存占用情况,比如都比较高,根本原因是由于历史数据太多导致,应在业务层增加逻辑去定时关闭或删除索引
参考资料
线上 Elasticsearch 集群健康值 red 状态问题排查与解决 - 云+社区 - 腾讯云 (tencent.com)
Elasticsearch集群异常状态(RED、YELLOW)原因分析 - 云+社区 - 腾讯云 (tencent.com)
es实战-分片分配失败解决方案_casterQ的博客-CSDN博客_es 分片失败