Re-define index.mapper.dynamic setting in 8.x #109341
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Forward port from elastic#109301 to main branch only, and also checks whether the setting gets archived. Relates to elastic#109160 and elastic#96075
martijnvg
added
>test
martijnvg
changed the title
martijnvg
added
v8.14.1
>bug
and removed
>test
|
Hi @martijnvg, I've created a changelog YAML for you. |
|
Pinging @elastic/es-storage-engine (Team:StorageEngine) |
dnhatn
approved these changes
Jun 10, 2024
| @@ -147,6 +147,18 @@ public boolean isAutoUpdate() { | |||
| Property.Dynamic, | |||
| Property.IndexScope | |||
| ); | |||
| /** | |||
| * Legacy index setting, kept for 7.x BWC compatibility. This setting has no effect in 8.x. Do not use. | |||
| * TODO: Remove in 9.0 | |||
There was a problem hiding this comment.
Can we use @UpdateForV9 instead of TODO?
kkrik-es
approved these changes
Jun 10, 2024
martijnvg
added
auto-merge-without-approval
martijnvg
added a commit
to martijnvg/elasticsearch
that referenced
this pull request
Jun 11, 2024
Currently when upgrading a 7.x cluster to 8.x with `index.mapper.dynamic` index setting defined the following happens: - In case of a full cluster restart upgrade, then the index setting gets archived and after the upgrade the cluster is in a green health. - In case of a rolling cluster restart upgrade, then shards of indices with the index setting fail to allocate as nodes start with 8.x version. The result is that the cluster has a red health and the index setting isn't archived. Closing and opening the index should archive the index setting and allocate the shards. The change is about ensuring the same behavior happens when upgrading a cluster from 7.x to 8.x with indices that have the `index.mapper.dynamic` index setting defined. By re-defining the `index.mapper.dynamic `index setting with `IndexSettingDeprecatedInV7AndRemovedInV8` property, the index is allowed to exist in 7.x indices, but can't be defined in new indices after the upgrade. This way we don't have to rely on index archiving and upgrading via full cluster restart or rolling restart will yield the same outcome. Based on the test in elastic#109301. Relates to elastic#109160 and elastic#96075
💚 Backport successful
|
elasticsearchmachine
pushed a commit
that referenced
this pull request
Jun 11, 2024
Currently when upgrading a 7.x cluster to 8.x with `index.mapper.dynamic` index setting defined the following happens: - In case of a full cluster restart upgrade, then the index setting gets archived and after the upgrade the cluster is in a green health. - In case of a rolling cluster restart upgrade, then shards of indices with the index setting fail to allocate as nodes start with 8.x version. The result is that the cluster has a red health and the index setting isn't archived. Closing and opening the index should archive the index setting and allocate the shards. The change is about ensuring the same behavior happens when upgrading a cluster from 7.x to 8.x with indices that have the `index.mapper.dynamic` index setting defined. By re-defining the `index.mapper.dynamic `index setting with `IndexSettingDeprecatedInV7AndRemovedInV8` property, the index is allowed to exist in 7.x indices, but can't be defined in new indices after the upgrade. This way we don't have to rely on index archiving and upgrading via full cluster restart or rolling restart will yield the same outcome. Based on the test in #109301. Relates to #109160 and #96075
javanna
added a commit
to javanna/elasticsearch
that referenced
this pull request
Sep 17, 2024
This setting had been removed in the past, it was reintroudced for bw comp with 7.x with elastic#109341. It can now be removed from main as it no longer supports indices created with 7.x
javanna
added a commit
that referenced
this pull request
Sep 18, 2024
This setting had been removed in the past, it was reintroudced for bw comp with 7.x with #109341. It can now be removed from main as it no longer supports indices created with 7.x
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently when upgrading a 7.x cluster to 8.x with
index.mapper.dynamicindex setting defined the following happens:The change is about ensuring the same behavior happens when upgrading a cluster from 7.x to 8.x with indices that have the
index.mapper.dynamicindex setting defined. By re-defining theindex.mapper.dynamicindex setting withIndexSettingDeprecatedInV7AndRemovedInV8property, the index is allowed to exist in 7.x indices, but can't be defined in new indices after the upgrade. This way we don't have to rely on index archiving and upgrading via full cluster restart or rolling restart will yield the same outcome.Based on the test in #109301.
Relates to #109160 and #96075