honeymoose/OpenSearch
1
0
Fork 0
mirror of https://github.com/honeymoose/OpenSearch.git synced 2025-02-17 02:14:54 +00:00
Code Issues Packages Projects Releases Wiki Activity

Clarify that discovery ignores master-ineligibles (#44835)

Browse Source 
The changes in #32006 mean that the discovery process can no longer use
master-ineligible nodes as a stepping-stone between master-eligible nodes.
This was normally an indication of a strange and possibly-fragile configuration
and was not recommended, but this commit adds a note to the breaking changes
docs to note that this kind of configuration is more obviously broken in recent
versions.
This commit is contained in:
David Turner 2019-09-12 11:07:34 +01:00 committed by GitHub
parent 9f2c5632fe
commit 5c85b0998b
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 18 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
docs/reference/migration/migrate_7_0/discovery.asciidoc
View File

@ -70,3 +70,17 @@ pings, each of which times out after 10 seconds. Thus a node that is
unresponsive for longer than 30 seconds is liable to be removed from the
cluster. Previously the default timeout for each ping was 30 seconds, so that
an unresponsive node might be kept in the cluster for over 90 seconds.
[float]
==== Master-ineligible nodes are ignored by discovery
In earlier versions it was possible to use master-ineligible nodes during the
discovery process, either as seed nodes or to transfer discovery gossip
indirectly between the master-eligible nodes. Clusters that relied on
master-ineligible nodes like this were fragile and unable to automatically
recover from some kinds of failure. Discovery now involves only the
master-eligible nodes in the cluster so that it is not possible to rely on
master-ineligible nodes like this. You should configure
<<modules-discovery-hosts-providers,`discovery.seed_hosts` or another seed
hosts provider>> to provide the addresses of all the master-eligible nodes in
your cluster.

8
docs/reference/modules/discovery/discovery.asciidoc
View File

@ -11,10 +11,10 @@ This process starts with a list of _seed_ addresses from one or more
of any master-eligible nodes that were in the last-known cluster. The process
operates in two phases: First, each node probes the seed addresses by
connecting to each address and attempting to identify the node to which it is
connected. Secondly it shares with the remote node a list of all of its known
master-eligible peers and the remote node responds with _its_ peers in turn.
The node then probes all the new nodes that it just discovered, requests their
peers, and so on.
connected and to verify that it is master-eligible. Secondly, if successful, it
shares with the remote node a list of all of its known master-eligible peers
and the remote node responds with _its_ peers in turn. The node then probes all
the new nodes that it just discovered, requests their peers, and so on.
If the node is not master-eligible then it continues this discovery process
until it has discovered an elected master node. If no elected master is