解决elasticsearch集群Unassigned Shards无法reroute的问题

1.背景&问题描述

接上篇文章https://blog.csdn.net/dhaibo1986/article/details/107564968
在上一篇文章中,由于系统宕机,导致大量索引出现了Unassigned 状态。在上一篇文章中,我们通过reroute API进行了操作,对主分片缺失的索引,经过上述操作之后,分配了主分片。但是在接下来的操作中,对于副本分片,reroute出错!
如下是索引 alarm-2017.08.12,第0个分片的副本没有分配:
Paste_Image.png
下面执行语句:

  POST /_cluster/reroute
  {
  "commands": [
    {
      "allocate_replica": {
        "index": "alarm-2017.08.12",
        "shard": 0,
        "node": "node4-1"
      }
    }
  ]
}

结果执行失败!

{
  "error": {
    "root_cause": [
      {
        "type": "remote_transport_exception",
        "reason": "[node3-2][192.168.21.88:9301][cluster:admin/reroute]"
      }
    ],
    "type": "illegal_argument_exception",
    "reason": "[allocate_replica] allocation of [alarm-2017.08.12][0] on node {node4-1}{u47KtJGgQw60T_xm9hmepw}{UbaCHI4KRveQeTAnJvGFEQ}{192.168.21.89}{192.168.21.89:9301}{rack=r4, ml.enabled=true} is not allowed, reason: [NO(shard has exceeded the maximum number of retries [5] on failed allocation attempts - manually call [/_cluster/reroute?retry_failed=true] to retry, [unassigned_info[[reason=ALLOCATION_FAILED], at[2017-08-16T00:54:47.088Z], failed_attempts[5], delayed=false, details[failed recovery, failure RecoveryFailedException[[alarm-2017.08.12][0]: Recovery failed from {node8}{Bpd3y--EQsag1u1NTmtZfA}{4T_McpmjSXqLowRoXztssQ}{192.168.21.89}{192.168.21.89:9301}{rack=r4} into {node5}{i4oG4VcaSdKVeNEvStXwAw}{w4nAITEOR9u7liR55qDsVA}{192.168.21.88}{192.168.21.88:9300}{rack=r3}]; nested: RemoteTransportException[[node8][192.168.21.89:9301][internal:index/shard/recovery/start_recovery]]; nested: RecoveryEngineException[Phase[1] phase1 failed]; nested: RecoverFilesRecoveryException[Failed to transfer [0] files with total size of [0b]]; nested: FileSystemException[/opt/elasticsearch/elasticsearch-node8/data/nodes/0/indices/FgLdgYTmTfazlP8i5K0Knw/0/index: Too many open files in system]; ], allocation_status[no_attempt]]])][YES(primary shard for this replica is already active)][YES(explicitly ignoring any disabling of allocation due to manual allocation commands via the reroute API)][YES(target node version [5.5.1] is the same or newer than source node version [5.5.1])][YES(the shard is not being snapshotted)][YES(node passes include/ex
### 解决 Elasticsearch 集群中分片未分配 (unassigned) 的方法 当遇到Elasticsearch集群中的分片处于未分配状态时,可以采取多种措施来解决问题。通常情况下,这可能是由于节点间的通信问题、磁盘空间不足或是配置不当等原因造成的。 #### 检查集群健康状况 为了诊断具体原因,可以通过API请求获取当前集群的状态信息: ```bash curl -X GET "http://localhost:9200/_cluster/health?pretty" ``` 这条命令会返回有关整个集群健康的详情,包括活动的主分片数、副本数量以及是否有任何未分配的分片等重要指标[^2]。 #### 查看详细的分片分配情况 进一步了解哪些具体的索引或分片存在问题,可执行如下查询: ```bash curl -X GET "http://localhost:9200/_cat/shards?v=true&h=index,shard,prirep,state,node" ``` 此操作能够展示每一个分片的位置及其状态(例如`STARTED`, `UNASSIGNED`),从而帮助定位确切的问题所在。 #### 常见解决方案 - **重启相关节点**:如果某个数据节点突然离线,则可能导致其上的某些分片无法被重新分配给其他存活的数据节点;尝试重启该节点并观察恢复效果。 - **调整集群设置参数**: - 修改`cluster.routing.allocation.disk.watermark.low` 和 `high` 参数以适应实际可用存储容量; - 设置合理的`index.number_of_replicas`值确保有足够的副本来维持高可用性; - 调整`cluster.info.update.interval`使元数据更新更加频繁以便更快响应变化。 - **手动强制分配分片**:对于那些因为策略限制而未能自动迁移的情况,管理员可以选择通过特定指令来进行干预,比如使用以下RESTful API调用来指定目标节点完成分片的手动重置工作: ```json POST /_cluster/reroute { "commands": [ { "allocate_stale_primary": { "index": "your_index_name", "shard": 0, "node": "target_node_id_or_name", "accept_data_loss": true } } ] } ``` 注意,在这里设置了`accept_data_loss:true`意味着接受可能存在的数据丢失风险,请谨慎评估后再做决定[^1]。 #### 日志分析 最后但同样重要的一步是审查日志文件,特别是位于`logs/`目录下的`.log`记录,它们往往包含了最直接有价值的线索用于排查故障根源。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值