elasticsearch/docs/reference/tab-widgets/troubleshooting/data/migrate-to-data-tiers-routing-guide.asciidoc

223 lines
7.1 KiB
Text

// tag::cloud[]
In order to get the shards assigned we need to call the
<<ilm-migrate-to-data-tiers, migrate to data tiers routing>> API which will
resolve the conflicting routing configurations towards using the standardized
<<data-tiers, data tiers>>. This will also future-proof the system by migrating
the index templates and ILM policies if needed.
**Use {kib}**
//tag::kibana-api-ex[]
. Log in to the {ess-console}[{ecloud} console].
+
. On the **Elasticsearch Service** panel, click the name of your deployment.
+
NOTE: If the name of your deployment is disabled your {kib} instances might be
unhealthy, in which case please contact https://support.elastic.co[Elastic Support].
If your deployment doesn't include {kib}, all you need to do is
{cloud}/ec-access-kibana.html[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**.
+
[role="screenshot"]
image::images/kibana-console.png[{kib} Console,align="center"]
. First, let's <<ilm-stop,stop>> {ilm}
+
[source,console]
----
POST /_ilm/stop
----
//TEST[skip:stopping ILM requires waiting]
+
The response will look like this:
+
[source,console-result]
------------------------------------------------------------------------------
{
"acknowledged": true
}
------------------------------------------------------------------------------
// TESTRESPONSE[skip:the result is for illustrating purposes only]
. Wait for {ilm} to stop. Check the status until it returns `STOPPED` as follows:
+
[source,console]
----
GET /_ilm/status
----
+
When {ilm} has successfully stopped the response will look like this:
+
[source,console-result]
------------------------------------------------------------------------------
{
"operation_mode": "STOPPED"
}
------------------------------------------------------------------------------
// TESTRESPONSE[skip:not waiting for ILM to stop]
. <<ilm-migrate-to-data-tiers, Migrate to data tiers>>
+
[source,console]
----
POST /_ilm/migrate_to_data_tiers
----
//TEST[skip:this can flake as we're not waiting for ILM to stop]
+
The response will look like this:
+
[source,console-result]
------------------------------------------------------------------------------
{
"dry_run": false,
"migrated_ilm_policies":["policy_with_allocate_action"], <1>
"migrated_indices":["warm-index-to-migrate-000001"], <2>
"migrated_legacy_templates":["a-legacy-template"], <3>
"migrated_composable_templates":["a-composable-template"], <4>
"migrated_component_templates":["a-component-template"] <5>
}
------------------------------------------------------------------------------
// TESTRESPONSE[skip:the result is for illustrating purposes only as we're not waiting for ILM to stop]
+
<1> The ILM policies that were updated.
<2> The indices that were migrated to <<tier-preference-allocation-filter,tier preference>> routing.
<3> The legacy index templates that were updated to not contain custom routing settings for the
provided data attribute.
<4> The composable index templates that were updated to not contain custom routing settings for the
provided data attribute.
<5> The component templates that were updated to not contain custom routing settings for the
provided data attribute.
. <<ilm-start,Restart>> {ilm}
+
[source,console]
----
POST /_ilm/start
----
+
The response will look like this:
+
[source,console-result]
------------------------------------------------------------------------------
{
"acknowledged": true
}
------------------------------------------------------------------------------
// TESTRESPONSE[skip:didn't wait to stop it]
//end::kibana-api-ex[]
// end::cloud[]
// tag::self-managed[]
In order to get the shards assigned we need to make sure the deployment is
using the <<data-tiers,data tiers>> node roles and then call the
<<ilm-migrate-to-data-tiers, migrate to data tiers routing>> API which will
resolve the conflicting routing configurations towards using the standardized
<<data-tiers, 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, data tiers>> <<assign-data-tier, 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.
+
[source,yaml]
----
node.roles [ data_hot, data_content ]
----
. <<ilm-stop,Stop>> {ilm}
+
[source,console]
----
POST /_ilm/stop
----
//TEST[skip:stopping ILM requires waiting]
+
The response will look like this:
+
[source,console-result]
------------------------------------------------------------------------------
{
"acknowledged": true
}
------------------------------------------------------------------------------
// TESTRESPONSE[skip:the result is for illustrating purposes only]
. Wait for {ilm} to stop. Check the status until it returns `STOPPED` as follows:
+
[source,console]
----
GET /_ilm/status
----
+
When {ilm} has successfully stopped the response will look like this:
+
[source,console-result]
------------------------------------------------------------------------------
{
"operation_mode": "STOPPED"
}
------------------------------------------------------------------------------
// TESTRESPONSE[skip:not waiting for ILM to stop]
. <<ilm-migrate-to-data-tiers, Migrate to data tiers>>
+
[source,console]
----
POST /_ilm/migrate_to_data_tiers
----
//TEST[skip:this can flake as we're not waiting for ILM to stop]
+
The response will look like this:
+
[source,console-result]
------------------------------------------------------------------------------
{
"dry_run": false,
"migrated_ilm_policies":["policy_with_allocate_action"], <1>
"migrated_indices":["warm-index-to-migrate-000001"], <2>
"migrated_legacy_templates":["a-legacy-template"], <3>
"migrated_composable_templates":["a-composable-template"], <4>
"migrated_component_templates":["a-component-template"] <5>
}
------------------------------------------------------------------------------
// TESTRESPONSE[skip:the result is for illustrating purposes only as we're not waiting for ILM to stop]
+
<1> The ILM policies that were updated.
<2> The indices that were migrated to <<tier-preference-allocation-filter,tier preference>> routing.
<3> The legacy index templates that were updated to not contain custom routing settings for the
provided data attribute.
<4> The composable index templates that were updated to not contain custom routing settings for the
provided data attribute.
<5> The component templates that were updated to not contain custom routing settings for the
provided data attribute.
. <<ilm-start,Restart>> {ilm}
+
[source,console]
----
POST /_ilm/start
----
+
The response will look like this:
+
[source,console-result]
------------------------------------------------------------------------------
{
"acknowledged": true
}
------------------------------------------------------------------------------
// TESTRESPONSE[skip:didn't wait to stop it]
// end::self-managed[]