UnicastZenPing should also ping last known discoNodes #7336
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
At the moment, when a node looses connection to the master (due to a partition or the master was stopped), we ping the unicast hosts in order to discover other nodes and elect a new master or get of another master than has been elected in the mean time. This can go wrong if all unicast targets are on the same side of a minority partition and therefore will never rejoin once the partition is healed.
| @@ -120,6 +131,12 @@ public DiscoveryNode electMaster(Iterable<DiscoveryNode> nodes) { | |||
|
|
|||
| @Override | |||
| public int compare(DiscoveryNode o1, DiscoveryNode o2) { | |||
| if (o1.masterNode() && !o2.masterNode()) { | |||
| return -1; | |||
There was a problem hiding this comment.
Shouldn't this return 1 and the other if statement return -1?
There was a problem hiding this comment.
Wait this code is ok, we want nodes with master eligible nodes to be in the beginning of the list and therefor it should be deemed smaller (return -1) then a node with that isn't master.
Maybe add a unit test for the elect master logic :)
|
Left one comment regarding unit test for elect logic, other than that LGTM. |
|
@martijnvg added unit tests. |
|
@bleskes LGTM |
|
lgtm |
bleskes
added a commit
that referenced
this pull request
Aug 20, 2014
At the moment, when a node looses connection to the master (due to a partition or the master was stopped), we ping the unicast hosts in order to discover other nodes and elect a new master or get of another master than has been elected in the mean time. This can go wrong if all unicast targets are on the same side of a minority partition and therefore will never rejoin once the partition is healed. Closes #7336
bleskes
added a commit
that referenced
this pull request
Aug 22, 2014
At the moment, when a node looses connection to the master (due to a partition or the master was stopped), we ping the unicast hosts in order to discover other nodes and elect a new master or get of another master than has been elected in the mean time. This can go wrong if all unicast targets are on the same side of a minority partition and therefore will never rejoin once the partition is healed. Closes #7336
bleskes
added a commit
that referenced
this pull request
Aug 23, 2014
At the moment, when a node looses connection to the master (due to a partition or the master was stopped), we ping the unicast hosts in order to discover other nodes and elect a new master or get of another master than has been elected in the mean time. This can go wrong if all unicast targets are on the same side of a minority partition and therefore will never rejoin once the partition is healed. Closes #7336
bleskes
added a commit
that referenced
this pull request
Aug 27, 2014
At the moment, when a node looses connection to the master (due to a partition or the master was stopped), we ping the unicast hosts in order to discover other nodes and elect a new master or get of another master than has been elected in the mean time. This can go wrong if all unicast targets are on the same side of a minority partition and therefore will never rejoin once the partition is healed. Closes #7336
bleskes
added a commit
to bleskes/elasticsearch
that referenced
this pull request
Sep 1, 2014
At the moment, when a node looses connection to the master (due to a partition or the master was stopped), we ping the unicast hosts in order to discover other nodes and elect a new master or get of another master than has been elected in the mean time. This can go wrong if all unicast targets are on the same side of a minority partition and therefore will never rejoin once the partition is healed. Closes elastic#7336
|
@bleskes Should we label this issue with 1.4.0 and 2.0.0? |
dadoonet
added a commit
to elastic/elasticsearch-cloud-aws
that referenced
this pull request
Sep 5, 2014
Introduced in elastic/elasticsearch#7336 (elasticsearch 1.4 and 2.0), we need to change Ec2Discovery constructor. Closes #115.
dadoonet
added a commit
to elastic/elasticsearch-cloud-aws
that referenced
this pull request
Sep 5, 2014
Introduced in elastic/elasticsearch#7336 (elasticsearch 1.4 and 2.0), we need to change Ec2Discovery constructor. Closes #115.
dadoonet
added a commit
to elastic/elasticsearch-cloud-azure
that referenced
this pull request
Sep 5, 2014
Introduced in elastic/elasticsearch#7336 (elasticsearch 1.4 and 2.0), we need to change AzureDiscovery constructor. Closes #34.
dadoonet
added a commit
to elastic/elasticsearch-cloud-azure
that referenced
this pull request
Sep 5, 2014
Introduced in elastic/elasticsearch#7336 (elasticsearch 1.4 and 2.0), we need to change AzureDiscovery constructor. Closes #34.
dadoonet
added a commit
to elastic/elasticsearch-cloud-gce
that referenced
this pull request
Sep 5, 2014
Introduced in elastic/elasticsearch#7336 (elasticsearch 1.4 and 2.0), we need to change GceDiscovery constructor. Closes #35.
dadoonet
added a commit
to elastic/elasticsearch-cloud-gce
that referenced
this pull request
Sep 5, 2014
Introduced in elastic/elasticsearch#7336 (elasticsearch 1.4 and 2.0), we need to change GceDiscovery constructor. Closes #35.
bleskes
added a commit
that referenced
this pull request
Sep 8, 2014
At the moment, when a node looses connection to the master (due to a partition or the master was stopped), we ping the unicast hosts in order to discover other nodes and elect a new master or get of another master than has been elected in the mean time. This can go wrong if all unicast targets are on the same side of a minority partition and therefore will never rejoin once the partition is healed. Closes #7336
clintongormley
changed the title
clintongormley
added
the
:Distributed/Discovery-Plugins
clintongormley
changed the title
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.
At the moment, when a node looses connection to the master (due to a partition or the master was stopped), we ping the unicast hosts in order to discover other nodes and elect a new master or get of another master than has been elected in the mean time. This can go wrong if all unicast targets are on the same side of a minority partition and therefore will never rejoin once the partition is healed.
Note: this is agains the
feature/improve_zenbranch