elasticsearch重启后,unassigned索引重新分片失败YELLO、RED恢复处理
作者:互联网
文章目录
现象
elasticsearch
索引重启后,集群状态yellow red
- 有时候自动恢复成
green
,有时候长时间不恢复 - 显示
unassigned
,索引分片失败 - 显示
initializing
,但长时间完成不了
排查与处理
信息查看
集群状态
- 查看集群状态,查看正在初始化和未分配的shard有多少
curl http://10.209.180.72:9200/_cluster/health?pretty
- 可以直观看到集群状态 所有分片数 正在创建分片数 未分片数
节点状态
- 如果是集群里有节点未启动,节点数量较少,从而导致已有节点不够完成分片分配,也导致类似问题
- 检查加入集群的节点,确认集群中所有节点都启动成功加入集群
curl http://10.209.180.72:9200/_cat/nodes?v&pretty
索引状态
- 查看所有索引的健康状态
curl http://10.209.180.72:9200/_cat/indices?pretty
- 可以确认yellow 或 red 的是哪些索引库导致的
- 在这里也可以查看索引id,在下面删除
translog
时会用到
分片状态
- 检查shards的健康状态
curl http://10.209.180.72:9200/_cat/shards?v
- 查看是哪些索引的哪些分片未分配启动成功
- 可以看到分片失败或正在初始化的,是主分片还是副本分片
- 可以查看失败原因
原因探究
查看unsigned原因
- 查看磁盘使用情况,排查是否是磁盘接近满了导致的
curl -s 'http://10.209.180.72:9200/_cat/allocation?v'
- 查看allocation失败原因
curl http://10.209.180.72:9200/_cluster/allocation/explain?pretty
- 此方法执行后,可以查看分片失败具体原因
主动重新分片
- 一般分片失败后,超过重试次数(一般5次)就不再重试,可以使用reroute命令主动重试
- 接着进行分片重试,如果是yellow状态,执行此方法一般就能解决
curl -XPOST 'http://10.209.180.72:9200/_cluster/reroute?retry_failed=true'
- 如果执行此方法无效,可以手动对某索引库进行分片
- 重新分片 主分片
curl -H "Content-Type: application/json" -X POST -d '{
"commands": [
{
"allocate_stale_primary": {
"index": "gov_c",
"shard": 1,
"node": "node-3-74-9200",
"accept_data_loss" : true
}
}
]
}' "http://10.209.180.72:9200/_cluster/reroute"
- 重新分片 副本分片
curl -H "Content-Type: application/json" -X POST -d '{
"commands": [
{
"allocate_replica": {
"index": "gov_c",
"shard": 1,
"node": "node-3-74-9200"
}
}
]
}' "http://10.209.180.72:9200/_cluster/reroute"
主动分片失败解决
如果以上还是失败,则说明问题不小,要做好数据丢失的心理准备
- 1、继续执行上面查看分片失败原因的方法,查看此时还未恢复正常的分片
curl -XGET 'http://10.209.180.72:9200/_cluster/allocation/explain?pretty'
- 2、查看全部分片恢复情况,主要查看不是
done
状态的
curl http://10.209.180.72:9200/_cat/recovery?v&h=i,s,t,ty,st,shost,thost,f,fp,b,bp,to,tor,top&active_only
- 3、上面一个结果太多,可以指定索引库,查看分片恢复情况,主要查看是否为
"stage" : "DONE"
,如果不是查看具体处于哪个阶段,在这个阶段已经花费了多少时间,如果长时间(几小时)没结束,应该就是卡死了
curl http://10.209.180.72:9200/gov_c/_recovery?pretty=true
- 4、此次看到一直初始化
initializing
的translog
阶段,而且长达十几小时,按照百分比计算,以为还有2小时后结束就没管了,结果到了第二天还没结束,恢复百分比也没变化,这时候认为应该是卡死了 - 5、查看现有正在执行的任务
curl http://10.209.180.72:9200/_cat/tasks
- 发现有线程执行了二十小时也没完成,确定没救了
- 6、查看了下卡死的
translog
,发现只有几十兆大小,现在只能考虑删除translog舍弃一部分数据,再重启了 - 使用
curl http://10.209.180.72:9200/gov_c/_recovery?pretty=true
查看具体translog
状态的索引名称、问题节点名称和分片id,去对应节点的elasticsearch目录执行
bin/elasticsearch-translog truncate -d data/nodes/0/indices/3t1xcXNXTqa4yLWi5mShrw/1/translog
- 特别注意:需要先关闭es服务再执行,需要使用es用户执行。因为使用root执行后,重新生成的文件,是root权限,es服务没有权限读写
标签:10.209,http,9200,YELLO,unassigned,180.72,分片,elasticsearch,curl 来源: https://blog.csdn.net/u010882234/article/details/122343497