honeymoose
/
OpenSearch
mirror of https://github.com/honeymoose/OpenSearch.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

[DOCS] Fix broken links for 7.0 release (#41036) 

* [DOCS] Remove references to deprecated 'zen.discovery.minimum_master_nodes' setting
This commit is contained in:
James Rodewig 2019-04-09 18:18:26 -04:00
parent cbae617898
commit 2e2e11f7b4
1 changed files with 4 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
docs/resiliency/index.asciidoc
View File

@ -279,24 +279,22 @@ shard will be allocated upon reopening the index.
[float] [float]
=== Use two phase commit for Cluster State publishing (STATUS: DONE, v5.0.0) === Use two phase commit for Cluster State publishing (STATUS: DONE, v5.0.0)
A master node in Elasticsearch continuously https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-discovery-zen.html#fault-detection[monitors the cluster nodes] A master node in Elasticsearch continuously https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-fault-detection.html[monitors the cluster nodes]
and removes any node from the cluster that doesn't respond to its pings in a timely and removes any node from the cluster that doesn't respond to its pings in a timely
fashion. If the master is left with fewer nodes than the `discovery.zen.minimum_master_nodes` fashion. If the master is left with too few nodes, it will step down and a new master election will start.
settings, it will step down and a new master election will start.
When a network partition causes a master node to lose many followers, there is a short window When a network partition causes a master node to lose many followers, there is a short window
in time until the node loss is detected and the master steps down. During that window, the in time until the node loss is detected and the master steps down. During that window, the
master may erroneously accept and acknowledge cluster state changes. To avoid this, we introduce master may erroneously accept and acknowledge cluster state changes. To avoid this, we introduce
a new phase to cluster state publishing where the proposed cluster state is sent to all nodes a new phase to cluster state publishing where the proposed cluster state is sent to all nodes
but is not yet committed. Only once enough nodes (`discovery.zen.minimum_master_nodes`) actively acknowledge but is not yet committed. Only once enough nodes actively acknowledge
the change, it is committed and commit messages are sent to the nodes. See {GIT}13062[#13062]. the change, it is committed and commit messages are sent to the nodes. See {GIT}13062[#13062].
[float] [float]
=== Wait on incoming joins before electing local node as master (STATUS: DONE, v2.0.0) === Wait on incoming joins before electing local node as master (STATUS: DONE, v2.0.0)
During master election each node pings in order to discover other nodes and validate the liveness of existing During master election each node pings in order to discover other nodes and validate the liveness of existing
nodes. Based on this information the node either discovers an existing master or, if enough nodes are found nodes. Based on this information the node either discovers an existing master or, if enough nodes are found a new master will be elected. Currently, the node that is
(see https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-discovery-zen.html#master-election[`discovery.zen.minimum_master_nodes`]) a new master will be elected. Currently, the node that is
elected as master will update the cluster state to indicate the result of the election. Other nodes will submit elected as master will update the cluster state to indicate the result of the election. Other nodes will submit
a join request to the newly elected master node. Instead of immediately processing the election result, the elected master a join request to the newly elected master node. Instead of immediately processing the election result, the elected master
node should wait for the incoming joins from other nodes, thus validating that the result of the election is properly applied. As soon as enough node should wait for the incoming joins from other nodes, thus validating that the result of the election is properly applied. As soon as enough