Indices mix index allocation filters with data tiers node roles to move through data tiers
editIndices mix index allocation filters with data tiers node roles to move through data tiers
editElasticsearch 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
resp = client.ilm.stop() print(resp)
response = client.ilm.stop puts response
const response = await client.ilm.stop(); console.log(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
STOPPEDas follows:resp = client.ilm.get_status() print(resp)
response = client.ilm.get_status puts response
const response = await client.ilm.getStatus(); console.log(response);
GET /_ilm/status
When index lifecycle management has successfully stopped the response will look like this:
{ "operation_mode": "STOPPED" } -
resp = client.ilm.migrate_to_data_tiers() print(resp)
response = client.ilm.migrate_to_data_tiers puts response
const response = await client.ilm.migrateToDataTiers(); console.log(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
resp = client.ilm.start() print(resp)
response = client.ilm.start puts response
const response = await client.ilm.start(); console.log(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, ordata_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
resp = client.ilm.stop() print(resp)
response = client.ilm.stop puts response
const response = await client.ilm.stop(); console.log(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
STOPPEDas follows:resp = client.ilm.get_status() print(resp)
response = client.ilm.get_status puts response
const response = await client.ilm.getStatus(); console.log(response);
GET /_ilm/status
When index lifecycle management has successfully stopped the response will look like this:
{ "operation_mode": "STOPPED" } -
resp = client.ilm.migrate_to_data_tiers() print(resp)
response = client.ilm.migrate_to_data_tiers puts response
const response = await client.ilm.migrateToDataTiers(); console.log(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
resp = client.ilm.start() print(resp)
response = client.ilm.start puts response
const response = await client.ilm.start(); console.log(response);
POST /_ilm/start
The response will look like this:
{ "acknowledged": true }