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服务没有权限读写

elasticsearch重启后，unassigned索引重新分片失败YELLO、RED恢复处理

文章目录

现象

排查与处理

信息查看

集群状态

节点状态

索引状态

分片状态

原因探究

查看unsigned原因

主动重新分片

主动分片失败解决

相关推荐