ElasticSearch重启之后shard未分配问题的解决

在Elasticsearch集群中,若遇到部分分片未分配且集群状态为黄色的问题,可能是由于分片分配达到最大重试次数。通过执行reroute命令,可使ES重新尝试分配分片,恢复正常状态。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

 

环境:

  • Ubuntu16.04
  • elasticsearch 6.2.3
  • 3个master节点,10个data节点
  • 每个分片有一个副本

故障:

    将一个数据节点的elasticsearch换成docker elasticsearch,分词器没有添加到plugins中。随后把分词器添加到plugins中后,发现有的分片没有被分配,但是ES集群启动正常,只不过一直是yellow状态。而且unassigned分片一直未被分配

解决办法

首先执行:GET user/_recovery?active_only=true 发现集群并没有进行副本恢复。

点击未进行分配的分片,发现allocation_status: "no_attempt"

原因是:shard 自动分配 已经达到最大重试次数5次,仍然失败了,所以导致"shard的分配状态已经是:no_attempt"。这时在Kibana Dev Tools,执行命令:POST /_cluster/reroute?retry_failed=true即可。由index.allocation.max_retries参数来控制最大重试次数。

The cluster will attempt to allocate a shard a maximum of index.allocation.max_retries times in a row (defaults to 5), before giving up and leaving the shard unallocated.

当执行reroute命令对分片重新路由后,ElasticSearch会自动进行负载均衡,负载均衡参数cluster.routing.rebalance.enable默认为true。 

It is important to note that after processing any reroute commands Elasticsearch will perform rebalancing as normal (respecting the values of settings such as cluster.routing.rebalance.enable) in order to remain in a balanced state.

 总结

一般来说,ElasticSearch会自动分配 那些 unassigned shards,当发现某些shards长期未分配时,首先看下是否是因为:为索引指定了过多的primary shard 和 replica 数量,然后集群中机器数量又不够。另一个原因就是本文中提到的:由于故障,shard自动分配达到了最大重试次数了,这时执行 reroute 就可以了。

<think>好的,我现在需要解决用户提到的Elasticsearch中传入分片恢复限制的问题。用户想提高这个限制,当前默认是10,导致恢复分片时可能遇到瓶颈。首先,我得回忆一下Elasticsearch的相关配置参数。 根据之前的知识,分片恢复相关的设置主要在集群配置里。可能相关的参数是`cluster.routing.allocation.node_concurrent_recoveries`,这个控制每个节点同时进行的分片恢复数量,包括传入和传出。但用户的问题特别提到传入分片,可能需要另一个参数。或者,可能这个参数同时控制两者,而默认值是10,所以用户需要调高它。 另外,可能还有其他设置,比如`cluster.routing.allocation.node_concurrent_incoming_recoveries`和`node_concurrent_outgoing_recoveries`,分别控制传入和传出的并发数。如果默认情况下,Elasticsearch使用`node_concurrent_recoveries`作为两者的默认值,那么用户可能需要单独调整传入的数值。 接下来需要确认这些参数的具体名称和用法。比如,是否在较新版本中,Elasticsearch将传入和传出的恢复分开设置。查阅资料的话,比如官方文档,可能提到在7.x版本后,可以分别设置`cluster.routing.allocation.node_concurrent_incoming_recoveries`和`cluster.routing.allocation.node_concurrent_outgoing_recoveries`,而`node_concurrent_recoveries`则作为两者的默认值。 然后,用户需要动态更新这些配置,不需要重启集群。可以通过PUT请求更新集群设置,例如: ``` PUT /_cluster/settings { "transient": { "cluster.routing.allocation.node_concurrent_incoming_recoveries": 20 } } ``` 同时,还要考虑其他相关参数,比如分片平衡设置`cluster.routing.rebalance.enable`,可能在恢复期间暂时禁用,避免资源竞争。另外,主节点的恢复限制`cluster.routing.allocation.node_initial_primaries_recoveries`也可能影响初始分片的分配,默认是4,可能需要调整。 另外,用户的问题可能与分片分配有关,比如引用[3]中提到的shard unassigned的情况,这时候除了调整恢复限制,还需要检查分片分配的原因,比如磁盘空间、节点角色配置是否正确等。例如,引用[4]中提到迁移失败的问题,可能与节点角色配置或分片分配策略有关,需要确保warm节点有足够的容量和正确的角色。 最后,建议用户调整参数后监控集群状态,使用`_cat/recovery` API查看恢复进度,以及检查日志是否有其他错误。同时提醒用户不要过度调高并发数,以免影响集群性能。</think>要解决Elasticsearch中传入分片恢复限制的问题,需调整相关集群参数并优化分片分配策略。以下是具体步骤和分析: --- ### 一、调整分片恢复并发限制 1. **修改传入分片恢复并发数** 默认情况下,Elasticsearch限制单个节点同时接收的分片恢复操作数为`10`。可通过以下参数动态调整(无需重启集群): ```json PUT /_cluster/settings { "transient": { "cluster.routing.allocation.node_concurrent_incoming_recoveries": 20 } } ``` 此参数控制单个节点**同时接收的分片恢复任务数**,调高后能加速分片分配[^1][^3]。 2. **调整总恢复并发数** 若需同时调整节点**传出分片恢复**的并发限制(默认`10`),可设置: ```json PUT /_cluster/settings { "transient": { "cluster.routing.allocation.node_concurrent_recoveries": 20 } } ``` 此参数综合控制节点**传入和传出的恢复任务总和**,适用于大规模分片迁移场景[^2]。 --- ### 二、优化分片分配策略 1. **临时禁用分片平衡** 在恢复期间禁用分片重平衡,避免资源竞争: ```json PUT /_cluster/settings { "transient": { "cluster.routing.rebalance.enable": "none" } } ``` 恢复完成后重新启用(设为`all`)。 2. **调整主分片恢复优先级** 提升主分片初始恢复速度(默认`4`): ```json PUT /_cluster/settings { "transient": { "cluster.routing.allocation.node_initial_primaries_recoveries": 10 } } ``` 主分片恢复优先级高于副本,此参数可加速索引可用性恢复[^1]。 --- ### 三、分片恢复失败排查 若调整参数后仍存在分片分配(`unassigned`),需检查: 1. **节点角色配置**:确认目标节点角色包含`data`角色(如冷热分层需检查`data_hot`/`data_warm`)[^4]。 2. **磁盘空间与水位线**:通过`GET _cat/allocation?v`检查节点磁盘使用率,确保超过水位线阈值。 3. **分片分配过滤规则**:排查`index.routing.allocation`相关设置是否限制分片分配。 --- ### 四、操作示例与验证 1. **查看当前恢复限制**: ```bash GET /_cluster/settings?include_defaults=true&filter_path=**.cluster.routing.allocation.node_concurrent* ``` 2. **监控恢复进度**: ```bash GET /_cat/recovery?v&active_only=true ``` ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值