526互联

记录ElasticSearch分片被锁定导致无法分配处理过程

发布时间 2023-11-07 10:59:49作者: pursuer.chen
本篇文章记录最近ES做节点替换，从shard迁移过程中被锁定导致无法分配，主shard正常，希望可以帮助其它人
failed to create shard，failed to obtain in-memory shard lock，ShardLockObtainFailedException

一、问题描述

这次遇到的问题比较特殊，尝试过以下几种手段都没有恢复：

  1. _cluster/reroute手动分片shard
  2. 由于是从shard无法分片，所以当时试过将所以的副本改成0，然后再设置成1，想通过重新生成副本来解决，结果也失败

接下来是排查问题的过程：

1、通过“GET _cat/shards/indexname”错误信息如下，从shard无法分配，主shard正常，正常的shard未展示出来：
indexname                3     r      UNASSIGNED                                 
indexname                4     r      UNASSIGNED                                 
indexname                1     r      UNASSIGNED

之前在运维过程中也遇到过UNASSIGNED这种从shard无法分配的问题，通过"allocate_replica"命令手动分配可以解决，这类问题一般都是因为node节点重启或者失联导致的shard分片异常

2、通过“GET _cluster/allocation/explain”错误信息如下：

"index": "indexname",
  "shard": 3,
  "primary": false,
  "current_state": "unassigned",
  "unassigned_info": {
    "reason": "ALLOCATION_FAILED",
    "at": "2023-11-02T18:43:14.758Z",
    "failed_allocation_attempts": 300,
    "details": "failed shard on node [4MMOUt8-SMatWGCzX1asAQ]: failed to create shard, failure IOException[failed to obtain in-memory shard lock]; nested: ShardLockObtainFailedException[[indexname][3]: obtaining shard lock timed out after 5000ms]; ",
    "last_allocation_status": "no_attempt"
  },
  "can_allocate": "no",
  "allocate_explanation": "cannot allocate because allocation is not permitted to any of the nodes",

大多数情况下shard的allocate相关的问题都可以通过“GET _cluster/allocation/explain”命令获取到有用的关键信息，从返回的内容来分析是索引的第3个shard导致的，在node节点[4MMOUt8-SMatWGCzX1asAQ]被锁定。

二、处理过程

知道问题原因了就有方法解决了，我准备了三套方案，如下：

前置工作

  1. 业务将索引的读写请求切走
  2. 创建一个测试索引验证shard是否都正常
  3. 备份索引数据

方案1：重启索引

--刷新索引
POST indexname/_flush
--关闭索引
POST indexname/_close
---打开索引
POST indexname/_open

在本次处理过程中，使用了方案1重启索引就已经把问题解决了，但是方案一还是的业务配合将读写请求切走，否则索引close会导致应用的请求报错

方案2：重启节点node节点

[4MMOUt8-SMatWGCzX1asAQ]

PUT _cluster/settings
{
"persistent": {
"cluster.routing.allocation.enable": "none"
}
}

PUT _cluster/settings
{
"persistent": {
"cluster.routing.allocation.enable": "all"
}
}

方案2重启锁定shard的节点理论上来说也是可以解决这个问题，但是因为方案一已经解决了问题就没机会做测试

方案3.重建索引

  1. 先还原备份到一个临时索引，验证数据没问题
  2. 删除当前索引，还原创建新索引
方案3是最后的方案了，如果方案1和2都解决不了的话只能通过方案3进行索引重建来解决，通过备份还原的方式来恢复索引其实也是很快的

三、思考总结

其实整个问题处理过程中还有一些其它的细节在文中没有提到，就是集群在默认开启自动shard均衡过程中由于shard多长尝试分片无法成功，达到默认的5次重试之后就会报错，这个时候其实可以尝试将集群的自动分片关闭"cluster.routing.allocation.enable": "none"，然后执行"POST /_cluster/reroute?retry_failed=true"来重置计数，最后通过手动分片shard的方式来做迁移也有可能能解决问题。只不过在每次遇到问题的时候需要结合当时的最佳场景去做判断，寻找影响范围最小的方案；

 

备注：

    作者：pursuer.chen

    博客：http://www.cnblogs.com/chenmh

本站点所有随笔都是原创，欢迎大家转载；但转载时必须注明文章来源，且在文章开头明显处给明链接。

《欢迎交流讨论》