Skip to content

Commit 2e2e11f

Browse files
committed
[DOCS] Fix broken links for 7.0 release (#41036)
* [DOCS] Remove references to deprecated 'zen.discovery.minimum_master_nodes' setting
1 parent cbae617 commit 2e2e11f

File tree

1 file changed

+4
-6
lines changed

1 file changed

+4
-6
lines changed

docs/resiliency/index.asciidoc

+4-6
Original file line numberDiff line numberDiff line change
@@ -279,24 +279,22 @@ shard will be allocated upon reopening the index.
279279
[float]
280280
=== Use two phase commit for Cluster State publishing (STATUS: DONE, v5.0.0)
281281

282-
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]
282+
A master node in Elasticsearch continuously https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-fault-detection.html[monitors the cluster nodes]
283283
and removes any node from the cluster that doesn't respond to its pings in a timely
284-
fashion. If the master is left with fewer nodes than the `discovery.zen.minimum_master_nodes`
285-
settings, it will step down and a new master election will start.
284+
fashion. If the master is left with too few nodes, it will step down and a new master election will start.
286285

287286
When a network partition causes a master node to lose many followers, there is a short window
288287
in time until the node loss is detected and the master steps down. During that window, the
289288
master may erroneously accept and acknowledge cluster state changes. To avoid this, we introduce
290289
a new phase to cluster state publishing where the proposed cluster state is sent to all nodes
291-
but is not yet committed. Only once enough nodes (`discovery.zen.minimum_master_nodes`) actively acknowledge
290+
but is not yet committed. Only once enough nodes actively acknowledge
292291
the change, it is committed and commit messages are sent to the nodes. See {GIT}13062[#13062].
293292

294293
[float]
295294
=== Wait on incoming joins before electing local node as master (STATUS: DONE, v2.0.0)
296295

297296
During master election each node pings in order to discover other nodes and validate the liveness of existing
298-
nodes. Based on this information the node either discovers an existing master or, if enough nodes are found
299-
(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
297+
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
300298
elected as master will update the cluster state to indicate the result of the election. Other nodes will submit
301299
a join request to the newly elected master node. Instead of immediately processing the election result, the elected master
302300
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

0 commit comments

Comments
 (0)