IMPORTANT: No additional bug fixes or documentation updates will be released for this version. For the latest information, see the current release documentation.

« Allow Elasticsearch to allocate the index Not enough nodes to allocate all shard replicas »

› ›

Indices mix index allocation filters with data tiers node roles to move through data tiers

edit

Indices mix index allocation filters with data tiers node roles to move through data tiers

edit

Elasticsearch standardized the implementation of hot-warm-cold architectures to data tiers in version 7.10. Some indices and deployments might have not fully transitioned to data tiers and mix the new way of implementing the hot-warm-cold architecture with legacy based node attributes.

This could lead to unassigned shards or shards not transitioning to the desired tier.

In order to fix this follow the next steps:

In order to get the shards assigned we need to call the migrate to data tiers routing API which will resolve the conflicting routing configurations towards using the standardized data tiers. This will also future-proof the system by migrating the index templates and ILM policies if needed.

Use Kibana

Log in to the Elastic Cloud console.
On the Elasticsearch Service panel, click the name of your deployment.

If the name of your deployment is disabled your Kibana instances might be unhealthy, in which case please contact Elastic Support. If your deployment doesn’t include Kibana, all you need to do is enable it first.
Open your deployment’s side navigation menu (placed under the Elastic logo in the upper left corner) and go to Dev Tools > Console.

First, let’s stop index lifecycle management

response = client.ilm.stop
puts response

POST /_ilm/stop

The response will look like this:

{
  "acknowledged": true
}

Wait for index lifecycle management to stop. Check the status until it returns STOPPED as follows:
```
response = client.ilm.get_status
puts response
```
```
GET /_ilm/status
```
When index lifecycle management has succesfully stopped the response will look like this:
```
{
  "operation_mode": "STOPPED"
}
```

Migrate to data tiers

response = client.ilm.migrate_to_data_tiers
puts response

POST /_ilm/migrate_to_data_tiers

The response will look like this:

{
  "dry_run": false,
  "migrated_ilm_policies":["policy_with_allocate_action"], 
  "migrated_indices":["warm-index-to-migrate-000001"], 
  "migrated_legacy_templates":["a-legacy-template"], 
  "migrated_composable_templates":["a-composable-template"], 
  "migrated_component_templates":["a-component-template"] 
}

	The ILM policies that were updated.
	The indices that were migrated to tier preference routing.
	The legacy index templates that were updated to not contain custom routing settings for the provided data attribute.
	The composable index templates that were updated to not contain custom routing settings for the provided data attribute.
	The component templates that were updated to not contain custom routing settings for the provided data attribute.

Restart index lifecycle management

response = client.ilm.start
puts response

POST /_ilm/start

The response will look like this:

{
  "acknowledged": true
}

In order to get the shards assigned we need to make sure the deployment is using the data tiers node roles and then call the migrate to data tiers routing API which will resolve the conflicting routing configurations towards using the standardized data tiers. This will also future-proof the system by migrating the index templates and ILM policies if needed.

In case your deployment is not yet using data tiers assign data nodes to the appropriate data tier. Configure the appropriate roles for each data node to assign it to one or more data tiers: data_hot, data_content, data_warm, data_cold, or data_frozen. For example, the following setting configures a node to be a data-only node in the hot and content tiers.
```
node.roles [ data_hot, data_content ]
```

Stop index lifecycle management

response = client.ilm.stop
puts response

POST /_ilm/stop

The response will look like this:

{
  "acknowledged": true
}

Wait for index lifecycle management to stop. Check the status until it returns STOPPED as follows:
```
response = client.ilm.get_status
puts response
```
```
GET /_ilm/status
```
When index lifecycle management has succesfully stopped the response will look like this:
```
{
  "operation_mode": "STOPPED"
}
```

Migrate to data tiers

response = client.ilm.migrate_to_data_tiers
puts response

POST /_ilm/migrate_to_data_tiers

The response will look like this:

{
  "dry_run": false,
  "migrated_ilm_policies":["policy_with_allocate_action"], 
  "migrated_indices":["warm-index-to-migrate-000001"], 
  "migrated_legacy_templates":["a-legacy-template"], 
  "migrated_composable_templates":["a-composable-template"], 
  "migrated_component_templates":["a-component-template"] 
}

	The ILM policies that were updated.
	The indices that were migrated to tier preference routing.
	The legacy index templates that were updated to not contain custom routing settings for the provided data attribute.
	The composable index templates that were updated to not contain custom routing settings for the provided data attribute.
	The component templates that were updated to not contain custom routing settings for the provided data attribute.

Restart index lifecycle management

response = client.ilm.start
puts response

POST /_ilm/start

The response will look like this:

{
  "acknowledged": true
}

« Allow Elasticsearch to allocate the index Not enough nodes to allocate all shard replicas »