Clarify replica shard allocation step in rolling restart procedure #1246
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.
Updates the restart documentation to specify that setting
cluster.routing.allocation.enable
toprimaries
disables replica shard allocation, not all shard allocation.The phrase “disable shard allocation” seems to be a colloquial shorthand. Those experienced with Elasticsearch may implicitly understand it refers to replica shards during restarts, but this can be unclear to newer users.
Historically (and TIL 💡), the restart procedures (doc) used the
none
setting to fully disable shard allocation, which matched the “disable shard allocation” phrasing . In version 6.7, the recommended setting changed toprimaries
to allow primary shard allocation while avoiding unnecessary replica movement. However, the descriptive text was not updated to reflect this change, leaving behind a vestigial phrase from earlier behavior.Clarifying this language helps align the documentation with the actual behavior in the example API calls we provide and reduces the risk of misinterpretation (e.g., mistakenly using "none" instead of "primaries").