Reroute after node join is processed #11960
Closed
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
elastic#11776 has simplified our rerouting logic by removing a scheduled background reroute in favor of an explicit reroute during the cluster state processing of a node join (the only place where we didn't do it explicitly). While that change is conceptually good, it change semantics a bit in two ways: - shard listing actions underpinning shard allocation do not have access to that new node yet (causing errors during shard allocation see elastic#11923 - the very first cluster state published to a node already has shard assignments to it. This surfaced other issues we are working to fix separately This commit changes the reroute to be done post processing the initial join cluster state to side step these issues while we work on a longer term solution.
bleskes
added
v2.0.0-beta1
review
:Distributed/Discovery-Plugins
|
LGTM, thanks @bleskes! |
bleskes
added a commit
that referenced
this pull request
Jun 30, 2015
- shard listing actions underpinning shard allocation do not have access to that new node yet (causing errors during shard allocation see #11923 - the very first cluster state published to a node already has shard assignments to it. This surfaced other issues we are working to fix separately This commit changes the reroute to be done post processing the initial join cluster state to side step these issues while we work on a longer term solution. Closes #11960
szroland
pushed a commit
to szroland/elasticsearch
that referenced
this pull request
Jun 30, 2015
- shard listing actions underpinning shard allocation do not have access to that new node yet (causing errors during shard allocation see elastic#11923 - the very first cluster state published to a node already has shard assignments to it. This surfaced other issues we are working to fix separately This commit changes the reroute to be done post processing the initial join cluster state to side step these issues while we work on a longer term solution. Closes elastic#11960
clintongormley
added
>bug
and removed
:Distributed/Discovery-Plugins
bleskes
added a commit
to bleskes/elasticsearch
that referenced
this pull request
Jul 3, 2015
…join This commit fixes it and adds an assert that an initial cluster state from master never has shards assigned to this node
bleskes
added a commit
that referenced
this pull request
Jul 3, 2015
It is removed now :) Closes #12019
bleskes
added a commit
that referenced
this pull request
Jul 3, 2015
It is removed now :) Closes #12019
lcawl
added
:Distributed/Distributed
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.
#11776 has simplified our rerouting logic by removing a scheduled background reroute in favor of an explicit reroute during the cluster state processing of a node join (the only place where we didn't do it explicitly). While that change is conceptually good, it change semantics a bit in two ways:
shard listing actions underpinning shard allocation do not have access to that new node yet (causing errors during shard allocation see NoSuchNodeException during startup #11923
the very first cluster state published to a node already has shard assignments to it. This surfaced other issues we are working to fix separately
This commit changes the reroute to be done post processing the initial join cluster state to side step these issues while we work on a longer term solution.