Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot update settings for index from an invalid to a valid state #84758

Open
andreidan opened this issue Mar 8, 2022 · 4 comments
Open

Cannot update settings for index from an invalid to a valid state #84758

andreidan opened this issue Mar 8, 2022 · 4 comments
Labels
>bug :Data Management/Indices APIs APIs to create and manage indices and templates Supportability Improve our (devs, SREs, support eng, users) ability to troubleshoot/self-service product better. Team:Data Management Meta label for data/management team v7.17.3 v8.0.2 v8.1.4 v9.0.0

Comments

@andreidan
Copy link
Contributor

andreidan commented Mar 8, 2022

Elasticsearch Version

7.x, 8.x

Installed Plugins

No response

Java Version

bundled

OS Version

Darwin

Problem Description

We sometimes see indices with settings that have invalid values.
eg partially mounted indices that can only live in the frozen tier, somehow end up having a _tier_preference that's not data_frozen

only the [data_frozen] tier preference may be used for partial searchable snapshots (got: [data_content])]

The bigger problem is that updating the _tier_preference setting to a correct value is not possible in this case. We see stack traces in the form of:

at org.elasticsearch.cluster.routing.allocation.DataTier$DataTierSettingValidator.validate(DataTier.java:302)
	at org.elasticsearch.cluster.routing.allocation.DataTier$DataTierSettingValidator.validate(DataTier.java:269)
	at org.elasticsearch.common.settings.Setting.get(Setting.java:515)
	at org.elasticsearch.common.settings.Setting.get(Setting.java:485)
	at org.elasticsearch.common.settings.AbstractScopedSettings.validate(AbstractScopedSettings.java:598)
	at org.elasticsearch.common.settings.AbstractScopedSettings.validate(AbstractScopedSettings.java:507)
	at org.elasticsearch.common.settings.AbstractScopedSettings.validate(AbstractScopedSettings.java:477)
	at org.elasticsearch.indices.IndicesService.createIndexService(IndicesService.java:696)
	at org.elasticsearch.indices.IndicesService.verifyIndexMetadata(IndicesService.java:810)
	at org.elasticsearch.cluster.metadata.MetadataUpdateSettingsService$1.execute(MetadataUpdateSettingsService.java:271)
	at org.elasticsearch.cluster.ClusterStateUpdateTask.execute(ClusterStateUpdateTask.java:51)
	at org.elasticsearch.cluster.service.MasterService.executeTasks(MasterService.java:836)
	at org.elasticsearch.cluster.service.MasterService.calculateTaskOutputs(MasterService.java:403)
	at org.elasticsearch.cluster.service.MasterService.runTasks(MasterService.java:243)
	at org.elasticsearch.cluster.service.MasterService.access$100(MasterService.java:63)
	at org.elasticsearch.cluster.service.MasterService$Batcher.run(MasterService.java:170)
	at org.elasticsearch.cluster.service.TaskBatcher.runIfNotProcessed(TaskBatcher.java:146)
	at org.elasticsearch.cluster.service.TaskBatcher$BatchedTask.run(TaskBatcher.java:202)

The problem here is that MetadataUpdateSettingsService calls into IndicesService.verifyIndexMetadata which in turn attempts to create an IndexService using the current, invalid, IndexMetadata https://github.com/elastic/elasticsearch/blob/master/server%2Fsrc%2Fmain%2Fjava%2Forg%2Felasticsearch%2Findices%2FIndicesService.java#L794

Currently we have two solutions:

  1. delete the problematic indices in one DELETE call and then mount them again from snapshot OR
  2. upgrade to a higher version of Elasticsearch as we automatically
    update the tier preference for partially mounted indices to the correct data_frozen value
    ( code )

Steps to Reproduce

We're not sure yet how to get into this situation.

Logs (if relevant)

No response

@elasticmachine elasticmachine added the Team:Data Management Meta label for data/management team label Mar 8, 2022
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-data-management (Team:Data Management)

@romain-chanu
Copy link

As discussed with @andreidan , it will be beneficial to list of problematic indices in the error message as well. The error message only the [data_frozen] tier preference may be used for partial searchable snapshots (got: [data_content])] is too vague.

@gadekishore
Copy link
Contributor

If anyone visit this issue you can find all the problematic indices using below jq with settings.json file from diag:

jq -r 'keys[] as $k | "($k) (.[$k] | .settings.index.routing.allocation.include._tier_preference)"' settings.json | awk '{printf("%-40s\t%-20s\n",$1,$2)}'

@gmarouli gmarouli added v8.9.0 and removed v8.8.0 labels Apr 26, 2023
andreidan added a commit to andreidan/elasticsearch that referenced this issue May 9, 2023
The migrate action (although no allowed in the frozen phase) would seem
to convert `frozen` to `data_frozen,data_cold,data_warm,data_hot` tier
configuration. As the migrate action is not allowed in the frozen phase
this would never happen, however the code is confusing as it seems like
it could.

The migrate to data tiers routing service shared the code that converted
`frozen` to `data_frozen,data_cold,data_warm,data_hot` if it would
encounter an index without any `_tier_preference` setting allocated on a
node with the `data_frozen` role (again a seemingly impossible situaion)

As part of elastic#84758 we have
seen frozen indices with the `data_frozen,data_cold,data_warm,data_hot`
tier preference however we could never reproduce it.
elasticsearchmachine pushed a commit that referenced this issue May 9, 2023
…guration (#95934)

The migrate action (although no allowed in the frozen phase) would seem
to convert `frozen` to `data_frozen,data_cold,data_warm,data_hot` tier
configuration. As the migrate action is not allowed in the frozen phase
this would never happen, however the code is confusing as it seems like
it could.

The migrate to data tiers routing service shared the code used by the
`migrate` action that converted `frozen` to
`data_frozen,data_cold,data_warm,data_hot` if it would encounter an
index without any `_tier_preference` setting  but with a custom node
attribute configured to `frozen` e.g. `include.data: frozen`

As part of #84758 we have
seen frozen indices with the `data_frozen,data_cold,data_warm,data_hot`
tier preference however we could never reproduce it.

Relates to #84758
andreidan added a commit to andreidan/elasticsearch that referenced this issue May 9, 2023
…guration (elastic#95934)

The migrate action (although no allowed in the frozen phase) would seem
to convert `frozen` to `data_frozen,data_cold,data_warm,data_hot` tier
configuration. As the migrate action is not allowed in the frozen phase
this would never happen, however the code is confusing as it seems like
it could.

The migrate to data tiers routing service shared the code used by the
`migrate` action that converted `frozen` to
`data_frozen,data_cold,data_warm,data_hot` if it would encounter an
index without any `_tier_preference` setting  but with a custom node
attribute configured to `frozen` e.g. `include.data: frozen`

As part of elastic#84758 we have
seen frozen indices with the `data_frozen,data_cold,data_warm,data_hot`
tier preference however we could never reproduce it.

Relates to elastic#84758
andreidan added a commit to andreidan/elasticsearch that referenced this issue May 9, 2023
…guration (elastic#95934)

The migrate action (although no allowed in the frozen phase) would seem
to convert `frozen` to `data_frozen,data_cold,data_warm,data_hot` tier
configuration. As the migrate action is not allowed in the frozen phase
this would never happen, however the code is confusing as it seems like
it could.

The migrate to data tiers routing service shared the code used by the
`migrate` action that converted `frozen` to
`data_frozen,data_cold,data_warm,data_hot` if it would encounter an
index without any `_tier_preference` setting  but with a custom node
attribute configured to `frozen` e.g. `include.data: frozen`

As part of elastic#84758 we have
seen frozen indices with the `data_frozen,data_cold,data_warm,data_hot`
tier preference however we could never reproduce it.

Relates to elastic#84758
elasticsearchmachine pushed a commit that referenced this issue May 9, 2023
…guration (#95934) (#95965)

The migrate action (although no allowed in the frozen phase) would seem
to convert `frozen` to `data_frozen,data_cold,data_warm,data_hot` tier
configuration. As the migrate action is not allowed in the frozen phase
this would never happen, however the code is confusing as it seems like
it could.

The migrate to data tiers routing service shared the code used by the
`migrate` action that converted `frozen` to
`data_frozen,data_cold,data_warm,data_hot` if it would encounter an
index without any `_tier_preference` setting  but with a custom node
attribute configured to `frozen` e.g. `include.data: frozen`

As part of #84758 we have
seen frozen indices with the `data_frozen,data_cold,data_warm,data_hot`
tier preference however we could never reproduce it.

Relates to #84758
elasticsearchmachine pushed a commit that referenced this issue May 9, 2023
…guration (#95934) (#95966)

The migrate action (although no allowed in the frozen phase) would seem
to convert `frozen` to `data_frozen,data_cold,data_warm,data_hot` tier
configuration. As the migrate action is not allowed in the frozen phase
this would never happen, however the code is confusing as it seems like
it could.

The migrate to data tiers routing service shared the code used by the
`migrate` action that converted `frozen` to
`data_frozen,data_cold,data_warm,data_hot` if it would encounter an
index without any `_tier_preference` setting  but with a custom node
attribute configured to `frozen` e.g. `include.data: frozen`

As part of #84758 we have
seen frozen indices with the `data_frozen,data_cold,data_warm,data_hot`
tier preference however we could never reproduce it.

Relates to #84758
@stefnestor
Copy link
Contributor

stefnestor commented Jul 13, 2023

Alternative discovery JQ

# tier preference set and not to frozen
$ cat settings.json | jq 'to_entries[]|.key as $k| .value.settings.index| select($k|contains("partial-"))| select(.routing.allocation.include."_tier_preference"|contains("data_frozen")|not)|$k'

# more generic check to include if tier preference NULL
$ cat settings.json | jq -rc 'to_entries[]|.key as $k| .value.settings.index| select($k|contains("partial-"))| {i:$k, tp:.routing.allocation.include."_tier_preference"}' | grep -v "data_frozen" | count

@andreidan andreidan added the Supportability Improve our (devs, SREs, support eng, users) ability to troubleshoot/self-service product better. label Jul 14, 2023
@quux00 quux00 added v8.11.0 and removed v8.10.0 labels Aug 16, 2023
@mattc58 mattc58 added v8.12.0 and removed v8.11.0 labels Oct 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>bug :Data Management/Indices APIs APIs to create and manage indices and templates Supportability Improve our (devs, SREs, support eng, users) ability to troubleshoot/self-service product better. Team:Data Management Meta label for data/management team v7.17.3 v8.0.2 v8.1.4 v9.0.0
Projects
None yet
Development

No branches or pull requests