參看網址：https://www.elastic.co/guide/cn/elasticsearch/guide/current/_delaying_shard_allocation.html
適用情況：對於一些網絡不穩定的情況比較適用（可能臨時有節點脫離集羣，然後又回來。時間很短）。這種情況，推遲分片分配可以很大程度上降低網絡和磁盤的負載。如果節點在超時之前回到集羣，至少可以減少1次的集羣再平衡，如果回到集羣的節點上的分片沒有數據更新（其他機器的主分片上），這個過程將會更快，對磁盤和網絡的壓力更小。
##使用方法：
通過參數 delayed_timeout ，等待時間可以全局設置也可以在索引級別進行修改:默認延時1分鐘
PUT /_all/_settings
{
"settings": {
"index.unassigned.node_left.delayed_timeout": "5m"
}
}
##解釋
通過使用 _all 索引名，我們可以爲集羣裏面的所有的索引使用這個參數，默認時間被修改成了 5 分鐘。
這個配置是動態的，可以在運行時進行修改。如果你希望分片立即分配而不想等待，你可以設置參數： delayed_timeout: 0.
注意：延遲分配不會阻止副本被提拔爲主分片。集羣還是會進行必要的提拔來讓集羣回到 yellow 狀態。缺失副本的重建是唯一被延遲的過程。
自動取消分片遷移：
如果節點在超時之後再回來，且集羣還沒有完成分片的移動，會發生什麼事情呢？在這種情形下， Elasticsearch 會檢查該機器磁盤上的分片數據和當前集羣中的活躍主分片的數據是不是一樣 — 如果兩者匹配， 說明沒有進來新的文檔，包括刪除和修改 — 那麼 master 將會取消正在進行的再平衡並恢復該機器磁盤上的數據。之所以這樣做是因爲本地磁盤的恢復永遠要比網絡間傳輸要快，並且我們保證了他們的分片數據是一樣的，這個過程可以說是雙贏。如果分片已經產生了分歧（比如：節點離線之後又索引了新的文檔），那麼恢復進程會繼續按照正常流程進行。重新加入的節點會刪除本地的、過時的數據，然後重新獲取一份新的。