You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/resiliency/index.asciidoc
+4-6
Original file line number
Diff line number
Diff line change
@@ -279,24 +279,22 @@ shard will be allocated upon reopening the index.
279
279
[float]
280
280
=== Use two phase commit for Cluster State publishing (STATUS: DONE, v5.0.0)
281
281
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]
283
283
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.
286
285
287
286
When a network partition causes a master node to lose many followers, there is a short window
288
287
in time until the node loss is detected and the master steps down. During that window, the
289
288
master may erroneously accept and acknowledge cluster state changes. To avoid this, we introduce
290
289
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
292
291
the change, it is committed and commit messages are sent to the nodes. See {GIT}13062[#13062].
293
292
294
293
[float]
295
294
=== Wait on incoming joins before electing local node as master (STATUS: DONE, v2.0.0)
296
295
297
296
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
300
298
elected as master will update the cluster state to indicate the result of the election. Other nodes will submit
301
299
a join request to the newly elected master node. Instead of immediately processing the election result, the elected master
302
300
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