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

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

文章目录

现象排查与处理

信息查看

集群状态节点状态索引状态分片状态 原因探究

查看unsigned原因主动重新分片主动分片失败解决

现象

elasticsearch索引重启后，集群状态yellow red有时候自动恢复成green，有时候长时间不恢复显示unassigned，索引分片失败显示initializing，但长时间完成不了 排查与处理 信息查看 集群状态

查看集群状态，查看正在初始化和未分配的shard有多少curl http://localhost:9200/_cluster/health?pretty可以直观看到集群状态 所有分片数 正在创建分片数 未分片数 节点状态

如果是集群里有节点未启动，节点数量较少，从而导致已有节点不够完成分片分配，也导致类似问题检查加入集群的节点，确认集群中所有节点都启动成功加入集群curl http://localhost:9200/_cat/nodes?v&pretty 索引状态

查看所有索引的健康状态curl http://localhost:9200/_cat/indices?pretty可以确认yellow 或 red 的是哪些索引库导致的在这里也可以查看索引id，在下面删除translog时会用到 分片状态

检查shards的健康状态curl http://localhost:9200/_cat/shards?v查看是哪些索引的哪些分片未分配启动成功可以看到分片失败或正在初始化的，是主分片还是副本分片可以查看失败原因 原因探究 查看unsigned原因

查看磁盘使用情况，排查是否是磁盘接近满了导致的curl -s 'http://localhost:9200/_cat/allocation?v'查看allocation失败原因curl http://localhost:9200/_cluster/allocation/explain?pretty此方法执行后，可以查看分片失败具体原因 主动重新分片

一般分片失败后，超过重试次数（一般5次）就不再重试，可以使用reroute命令主动重试接着进行分片重试，如果是yellow状态，执行此方法一般就能解决

curl -XPOST 'http://localhost: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://localhost: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://localhost:9200/_cluster/reroute"

主动分片失败解决

如果以上还是失败，则说明问题不小，要做好数据丢失的心理准备

1、继续执行上面查看分片失败原因的方法，查看此时还未恢复正常的分片

curl -XGET 'http://localhost:9200/_cluster/allocation/explain?pretty'

2、查看全部分片恢复情况，主要查看不是done状态的

curl http://localhost: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://localhost: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://localhost: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服务没有权限读写