通过手动迁移shard均匀分布热点数据的解决方案 - 检索分析服务Elasticsearch版

Elasticsearch通过哈希映射将文档均匀地路由到分片中，同时shard均匀地分散在各个数据节点中，这样可能会出现某些节点存储的热点数据较多，导致这些节点的负载较高的情况。针对这种情况，可采用重启集群或手动迁移shard的方式，重新分配shard，临时降低高负载节点的压力。本文介绍如何手动迁移shard。

问题场景

负载高的节点中存在大量的同一属性分片，例如仅存在主分片。
业务索引在负载高的节点存储的shard比其他节点多。
升配CPU后磁盘读写变高。可能原因：CPU升级后处理能力增强，单位时间内磁盘IO请求增加，且Segment Merge线程运行加快，导致写入量激增；或者集群重启后大索引的分片分布不均，集中在单一节点。处理方法：参见本文手动迁移shard，均衡节点负载。

注意事项

手动迁移shard，仅能临时解决节点压力较高的问题。如果节点短暂地脱离集群，shard重新分配，这些节点可能还会出现同样的问题。因此建议在迁移shard前，参见集群负载不均问题的分析方法及解决方案，优化shard后再迁移。
如果热点索引分配均衡，而集群整体压力较大，建议升配集群或扩容节点，解决资源紧张的问题。
读写请求路由机制：在shard处于RELOCATING状态期间，写请求始终路由到当前主分片所在节点（from_node），读请求因副本数为0仅能读取主分片，正常情况下读写请求不会失败。
迁移范围：手动迁移操作仅针对指定的主分片进行，不会影响同一索引下的其他主分片。
风险与规避：如果将索引的副本数设置为0，当主分片所在节点发生故障（如OOM、宕机）时，该分片会变为UNASSIGNED状态，导致索引状态变为RED、写入失败以及部分查询失败。建议在业务低峰期执行迁移，或者保留副本分片以便读请求可以分发到副本节点，降低迁移期间的风险。
并行迁移建议：数据量较小时，可以并行执行多个索引的主分片迁移；数据量较大（例如单个分片超过1 GB）时，建议逐个索引进行迁移，避免迁移过程中集群负载过高。
资源监控：执行迁移前，需要检查集群的磁盘空间和内存使用率，确认集群负载不高时再执行迁移操作。

解决方案

禁用分片分配。
```
PUT /_cluster/settings
{
  "transient" : {
     "cluster.routing.allocation.enable" : "none"
  }
}
```
重要以上命令仅临时禁用了分片分配，shard迁移完成后，需要重新启用（将cluster.routing.allocation.enable设置为all）。
手动迁移shard。
以下示例将index_parkingorder_v1索引，从192.168.130.77节点上的3号分片迁移到192.168.130.78节点上。
```
POST /_cluster/reroute
{
 "commands" : [
  {
   "move" : {
    "index" : "index_parkingorder_v1", 
    "shard" : 3,
    "from_node" : "192.168.130.77", 
    "to_node" : "192.168.130.78"
   }
  }
 ]
}
```
说明
- 迁移shard时，请确保同一序号的shard不能迁移到同一节点。例如，A节点中已经存在某一索引的3号副本分片，那么该索引的3号主分片就不能迁移到A节点中。
- 手动迁移shard更详细的说明，请参见cluster-reroute。
查看shard迁移状态。
```
GET _cat/shards?v
```
正常情况下，返回结果如下。
返回结果中，对应分片的state字段初始为RELOCATING，表示该分片正在迁移中；当state字段变为STARTED时，表示该分片已迁移完成。

shard迁移完成后，重新启用分片分配。

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