Use m_m_nodes from Zen1 master for Zen2 bootstrap #37701
Merged
Conversation
This file contains hidden or 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
To safely support rolling upgrades from 6.x to 7.x we need the 7.x nodes to have access to the `minimum_master_nodes` setting, but this setting is otherwise unnecessary in 7.x and we would like to remove it. Since a rolling upgrade from 6.x to 7.x involves the 7.x nodes joining a 6.x master, we can avoid the need for setting `minimum_master_nodes` on the 7.x nodes by copying the value set on the 6.x master. This change exposes the master's node-level value for `minimum_master_nodes` via a field in the cluster state.
Today we support a smooth rolling upgrade from Zen1 to Zen2 by automatically bootstrapping the cluster once all the Zen1 nodes have left, as long as the `minimum_master_nodes` count is satisfied. However this means that Zen2 nodes also require the `minimum_master_nodes` setting for this one specific and transient situation. Since nodes only perform this automatic bootstrapping if they previously belonged to a Zen1 cluster, they can keep track of the `minimum_master_nodes` setting from the previous master instead of requiring it to be set on the Zen2 node.
61 tasks
ywelsch
suggested changes
Jan 22, 2019
server/src/main/java/org/elasticsearch/cluster/ClusterState.java
Outdated
Show resolved
Hide resolved
server/src/main/java/org/elasticsearch/cluster/ClusterState.java
Outdated
Show resolved
Hide resolved
server/src/main/java/org/elasticsearch/cluster/coordination/DiscoveryUpgradeService.java
Outdated
Show resolved
Hide resolved
server/src/main/java/org/elasticsearch/cluster/coordination/DiscoveryUpgradeService.java
Outdated
Show resolved
Hide resolved
ywelsch
approved these changes
Jan 23, 2019
jasontedor
added a commit
to jasontedor/elasticsearch
that referenced
this pull request
Jan 24, 2019
* elastic/master: Optimize warning header de-duplication (elastic#37725) Bubble exceptions up in ClusterApplierService (elastic#37729) SQL: Improve handling of invalid args for PERCENTILE/PERCENTILE_RANK (elastic#37803) Remove unused ThreadBarrier class (elastic#37666) Add built-in user and role for code plugin (elastic#37030) Consolidate testclusters tests into a single project (elastic#37362) Fix docs for MappingUpdatedAction SQL: Introduce SQL DATE data type (elastic#37693) disabling bwc test while backporting elastic#37639 Mute ClusterDisruptionIT testAckedIndexing Set acking timeout to 0 on dynamic mapping update (elastic#31140) Remove index audit output type (elastic#37707) Mute FollowerFailOverIT testReadRequestsReturnsLatestMappingVersion [ML] Increase close job timeout and lower the max number (elastic#37770) Remove Custom Listeners from SnapshotsService (elastic#37629) Use m_m_nodes from Zen1 master for Zen2 bootstrap (elastic#37701) Fix index filtering in follow info api. (elastic#37752) Use project dependency instead of substitutions for distributions (elastic#37730) Update authenticate to allow unknown fields (elastic#37713) Deprecate HLRC EmptyResponse used by security (elastic#37540)
3 tasks
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.
Today we support a smooth rolling upgrade from Zen1 to Zen2 by automatically
bootstrapping the cluster once all the Zen1 nodes have left, as long as the
minimum_master_nodescount is satisfied. However this means that Zen2 nodesalso require the
minimum_master_nodessetting for this one specific andtransient situation.
Since nodes only perform this automatic bootstrapping if they previously
belonged to a Zen1 cluster, they can keep track of the
minimum_master_nodessetting from the previous master instead of requiring it to be set on the Zen2
node.
NB: The first commit on this branch, c69f13c, adds the
minimumMasterNodesOnPublishingMasterfield to the cluster state and is intended to be backported to 6.x. I'm starting with a single PR for the whole thing for initial discussion, then I will open a separate PR just for the backportable bits and merge & backport it first.