# Tier Preference is not using the secondary option for replica
**URL:** https://discuss.elastic.co/t/tier-preference-is-not-using-the-secondary-option-for-replica/364008
**Category:** Elasticsearch
**Created:** [July 29, 2024, 8:29pm UTC](https://discuss.elastic.co/t/tier-preference-is-not-using-the-secondary-option-for-replica/364008 "2024-07-29T20:29:58Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@jsheely](https://discuss.elastic.co/u/jsheely)
#### Post date: [July 29, 2024, 8:29pm UTC](https://discuss.elastic.co/t/tier-preference-is-not-using-the-secondary-option-for-replica/364008/1 "2024-07-29T20:29:58Z")
I am trying to utilize the \_tier\_preference setting of "data\_hot,data\_warm" so that all of my new indexes primary goes onto the HOT node and the replica for that index goes onto the WARM node.
However it ups the data on primary hot node but then goes into yellow state because it can't allocate the replica.
`index has a preference for tiers [data_hot,data_warm] and node does not meet the required [data_hot] tier"`
The node it is selecting does infact not have data\_hot but it does have data\_warm. Why is it not going to the next tier.
The documentation seems to say it should be allocating the next available node that meets the tier criteria
> **[Index-level data tier allocation filtering | Elasticsearch Guide \[8.14\] |...](https://www.elastic.co/guide/en/elasticsearch/reference/current/data-tier-shard-filtering.html)**
---
### Author:  [@jsheely](https://discuss.elastic.co/u/jsheely)
#### Post date: [July 29, 2024, 10:32pm UTC](https://discuss.elastic.co/t/tier-preference-is-not-using-the-secondary-option-for-replica/364008/2 "2024-07-29T22:32:58Z")
I found an older reference post that describes my problem exactly in more detail. However the described fix does not make sense to me.
> [@Shard allocation - strange behaviour of index tier preference](https://discuss.elastic.co/t/shard-allocation-strange-behaviour-of-index-tier-preference/326746/9):
>
> Can't get it to work. I created a brand new 2h/2w cluster. # Creating the index PUT test1 { "settings": { "index.routing.allocation.include.\_tier\_preference": null, "number\_of\_replicas": 2 } } # GET \_cat/shards/test1?v 200 OK index shard prirep state docs store ip node test1 0 p STARTED 0 225b 10.47.192.173 instance-0000000000 test1 0 r STARTED 0 225b 10.47.192.99 instance-0000000001 test1 0 r UNASSIGNED …
Setting \_tier\_preference to null seems to ignore desired result of having the settings to decide which tier I want the node to be on.
---
### Author:  [@leandrojmp](https://discuss.elastic.co/u/leandrojmp)
#### Post date: [July 30, 2024, 3:15am UTC](https://discuss.elastic.co/t/tier-preference-is-not-using-the-secondary-option-for-replica/364008/3 "2024-07-30T03:15:58Z")
> [@jsheely](#):
>
> I am trying to utilize the \_tier\_preference setting of "data\_hot,data\_warm" so that all of my new indexes primary goes onto the HOT node and the replica for that index goes onto the WARM node.
I don't think this is possible, this behavior does not make sense when using data tiers.
When you set `_tier_preference` to `data_hot,data_warm` you are telling elasticsearch that nodes with the `data_hot` role have preference to allocate shards for the indice, but if there are no nodes with the `data_hot` role in the cluster, then the shards should be allocate on nodes with the `data_warm` role.
If you have both roles in the cluster, then it will follow the preference order for both primary and replicas, you cannot have a primary shard on a `data_hot` node and a replica shard on a `data_warm` node.
Also, the reference post you shared is not the same thing you want to do.
> [@jsheely](#):
>
> Setting \_tier\_preference to null seems to ignore desired result of having the settings to decide which tier I want the node to be on.
Setting `_tier_preference` to null basically disables it and will allow the shards to be allocated on [any node](https://www.elastic.co/guide/en/elasticsearch/reference/current/data-tiers.html#data-tier-allocation).
> To remove the data tier preference setting, set the `_tier_preference` value to `null` . **This allows the index to allocate to any data node within the cluster**. Setting the `_tier_preference` to `null` does not restore the default value.
Can you provide more context on why you want to have a primary on a hot node and a replica on a warm node? As mentioned, this does not make sense when using data tier as hot nodes and warm nodes are expected to have difference hardware configurations for different goals.
---
### Author:  [@jsheely](https://discuss.elastic.co/u/jsheely)
#### Post date: [August 6, 2024, 5:06pm UTC](https://discuss.elastic.co/t/tier-preference-is-not-using-the-secondary-option-for-replica/364008/4 "2024-08-06T17:06:26Z")
The primary goal is that I want all new data coming in to be on the hot SSD storage node and the replica for those indexes on the warm node. I only have two nodes in my cluster.
The idea is that all new data is fast to query but is on the limited size SSD but has a back up on the warm larger HDD raid cluster.
I want to ensure there is always a replica but that it can be placed on the warm node.
---
### Author:  [@leandrojmp](https://discuss.elastic.co/u/leandrojmp)
#### Post date: [August 6, 2024, 5:55pm UTC](https://discuss.elastic.co/t/tier-preference-is-not-using-the-secondary-option-for-replica/364008/5 "2024-08-06T17:55:13Z")
Yeah, that's not possible.
To use data tiers and have replicas you need at least 2 nodes of the same tier, so you would need 2 hot nodes and 2 warm nodes.
With 2 nodes only, you should configure both nodes to have the same data tiers.
Also, a 2 node cluster is not resilient to failures, so sometimes it does not make much sense on having replicas and assume the risk of this. You can read more about resilience in small clusters on this [documentation](https://www.elastic.co/guide/en/elasticsearch/reference/current/high-availability-cluster-small-clusters.html).
In your case what you could do is to have a hot and warm node, but both without replicas, then you could have newer data on the hot tier and older data on the warm tier.
To have replicas in both cases you would need an extra hot node with the same specs and an extra warm node as well.