Skip to content

[DOCS] Fix broken links for 7.0 release #41036

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Apr 9, 2019
Merged

[DOCS] Fix broken links for 7.0 release #41036

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
36f03f8
[DOCS] Fix broken links for 7.0 release
jrodewig Apr 9, 2019
2d4aef6
[DOCS] Remove references to deprecated 'zen.discovery.minimum_master_…
jrodewig Apr 9, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 4 additions & 6 deletions docs/resiliency/index.asciidoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -279,24 +279,22 @@ shard will be allocated upon reopening the index.
[float]
=== 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]
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lcawl @debadair

Based on my local doc builds, it doesn't look like we can use attributes like {ref} here. Let me know if that's not the case.

If not, I'll create a separate issue to include those attributes and fix up this link. I didn't want to hold this fix up in the meantime.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't believe we have those attributes set up, no.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's just a matter of including the shared attributes...but I agree that it's not essential.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Due to the nature of the Resiliency page & the fact that we only publish one version of it, this is a case where linking to current makes sense.

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`
settings, it will step down and a new master election will start.
fashion. If the master is left with too few nodes, 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
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
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].

[float]
=== 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
nodes. Based on this information the node either discovers an existing master or, if enough nodes are found
(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
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
elected as master will update the cluster state to indicate the result of the election. Other nodes will submit
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Discovery has changed in 7.0 and the referenced setting is deprecated. Rather than simply removing the link, I'd remove the references to the discovery.zen.minimum_master_nodes setting and cross reference https://www.elastic.co/guide/en/elasticsearch/reference/7.0/modules-discovery-quorums.html#_master_elections for more information.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @debadair! I removed those references with 2d4aef6.

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
Expand Down