-
Notifications
You must be signed in to change notification settings - Fork 25k
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
Comments
Pinging @elastic/es-data-management (Team:Data Management) |
As discussed with @andreidan , it will be beneficial to list of problematic indices in the error message as well. The error message |
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)}' |
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.
…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
…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
…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
…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
…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
Alternative discovery JQ
|
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 notdata_frozen
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:The problem here is that
MetadataUpdateSettingsService
calls intoIndicesService.verifyIndexMetadata
which in turn attempts to create anIndexService
using the current, invalid,IndexMetadata
https://github.com/elastic/elasticsearch/blob/master/server%2Fsrc%2Fmain%2Fjava%2Forg%2Felasticsearch%2Findices%2FIndicesService.java#L794Currently we have two solutions:
DELETE
call and then mount them again from snapshot ORupdate 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
The text was updated successfully, but these errors were encountered: