手動遷移shard解決熱點資料分布不均-檢索分析服務 Elasticsearch版-阿里雲 - 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"
 }
}