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

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

 

环境:

  • 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 就可以了。

### 故障分析 在 Elasticsearch 重启过程中,出现 `primary shard is not active timeout` 错误,通常表示主分片能在指定时间内恢复并进入活跃状态。这种问题可能由多个因素导致,包括集群配置、节点启动顺序、磁盘 I/O 性能以及网络延迟等。 一个常见的原因是 **Shard Allocation 被手动关闭**,例如在滚动重启期间为了防止分片自动迁移而禁用了该功能,但重启完成后重新启用。这将导致主分片无法被正确分配,进而无法激活[^1]。 另一个常见情况是 **分片恢复并发数设置不合理**。Elasticsearch 允许通过 `cluster.routing.allocation.node_concurrent_recoveries` 参数控制每个节点同时进行的恢复操作数量。若此值设置过低或与实际硬件资源不匹配,可能导致恢复过程缓慢甚至超时[^3]。 此外,某些日志中会显示类似以下错误信息: ``` Caused by: org.elasticsearch.action.UnavailableShardsException: [.monitoring-kibana-7-2023.01.17][0] primary shard is not active Timeout: [1m], request: [BulkShardRequest [[.monitoring-kibana-7-2023.01.17][0]] containing [2] requests] ``` 这类异常表明,在执行写入请求时,主分片尚完成恢复,导致请求失败并抛出超时异常[^2]。 --- ### 解决方法 为解决上述问题,可以采取以下措施: 1. **确保 Shard Allocation 处于启用状态** 如果之前因维护或滚动重启关闭了分片分配,需使用如下命令重新开启: ```bash curl -XPUT 'localhost:9200/_cluster/settings' -H "Content-Type: application/json" -d '{ "transient": { "cluster.routing.allocation.enable": "all" } }' ``` 这将允许集群正常进行分片分配和恢复流程[^1]。 2. **调整分片恢复并发参数** 修改 `cluster.routing.allocation.node_concurrent_recoveries` 值以优化恢复性能。例如将其设为 3: ```json PUT _cluster/settings { "transient": { "cluster.routing.allocation.node_concurrent_recoveries": 3 } } ``` 此设置影响主分片和副本分片的恢复速度,合理调整可加快整个集群的恢复进程。 3. **检查集群健康状态与分配分片** 使用 `_cluster/health` 和 `_cat/shards` API 检查当前集群状态及哪些分片尚分配: ```bash GET _cluster/health?pretty GET _cat/shards?v ``` 若发现有分配的主分片,可通过 `_cluster/reroute` 手动触发分配: ```json POST _cluster/reroute { "commands": [ { "allocate_stale_primary": { "index": "your_index_name", "shard": 0, "node": "node_name", "accept_data_loss": false } } ] } ``` 注意:此操作应谨慎执行,避免数据丢失风险。 4. **延长恢复等待时间** 可适当增加 `cluster.recovery.initial_shards` 设置,以延长系统等待主分片恢复的时间窗口。例如: ```yaml cluster.recovery.initial_shards: 2 ``` 该参数控制集群在初始化阶段如何处理分片恢复,合理设置有助于提升稳定性。 5. **排查底层基础设施问题** 确保所有节点磁盘路径(`path.data`)权限正确且数据完整,同时监控 CPU、内存和磁盘 I/O 使用率。若存在硬件瓶颈,可能导致恢复过程缓慢或失败。 --- ###
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值