# Decommissioning a node using cluster.routing.allocation.exclude.\_name

**URL:** https://discuss.elastic.co/t/decommissioning-a-node-using-cluster-routing-allocation-exclude-name/284946
**Category:** Elasticsearch
**Created:** [September 22, 2021, 10:01pm UTC](https://discuss.elastic.co/t/decommissioning-a-node-using-cluster-routing-allocation-exclude-name/284946 "2021-09-22T22:01:13Z")
**Posts on this page:** 1
**Showing post:** 3

<div class="post-metadata">

### Author: ![linkerc](https://avatars.discourse-cdn.com/v4/letter/l/13edae/32.png) [@linkerc](https://discuss.elastic.co/u/linkerc)
#### Post date: [September 28, 2021, 12:16am UTC](https://discuss.elastic.co/t/decommissioning-a-node-using-cluster-routing-allocation-exclude-name/284946/3 "2021-09-28T00:16:27Z")

</div>

It has been fixed after we shutdown the node to be decommissioned, which caused the replica to become the primary.  
Some more background into our experience:  
The reason we want to decommission the node was AWS notification about potential HW failure. And I believe the reason shard relocation failed to finish was indeed due to disk drive failure. I encountered IO termination failure message when scp a particular file out of the failing AWS node  
as well. **This issue could've been avoided if the primary shard was switched to the replica as the first step.**

We will upgrade to the latest ASAP. But please take this suggestion into consideration for future releases if it has not been done already.

Once a node being marked as "exclude", the cluster should move all primary shards out of the node immediately.

linked topic: [Weird rebalancing strategy - #3 by linkerc](https://discuss.elastic.co/t/weird-rebalancing-strategy/285034/3)

---

_[View the full topic](https://discuss.elastic.co/t/decommissioning-a-node-using-cluster-routing-allocation-exclude-name/284946)._