Skip to content
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.

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

Docs: Document the most important changes to zen discovery. #7746

Closed
wants to merge 3 commits into from
Closed
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
7 changes: 7 additions & 0 deletions docs/reference/migration/migrate_1_x.asciidoc
Expand Up @@ -68,4 +68,11 @@ curl -XGET 'http://localhost:9200/_all/_mappings'
curl -XGET 'http://localhost:9200/_mappings'
--------------------------------------------------

==== Zen discovery

Each cluster must have an elected master node in order to be fully operational. Once a node loses its elected master
node it will reject operations.
Copy link
Contributor

Choose a reason for hiding this comment

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

maybe add some or all? i.e., "node it will reject some or all operations".


On versions before `1.4.0.Beta1` all operations are rejected when a node loses its elected master. From `1.4.0.Beta1`
only write operations will be rejected by default. Read operations can end up being partial and possible also be stale.
Copy link
Contributor

Choose a reason for hiding this comment

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

I think the read operations part should mention what happens. Something like "Read operations will still be served based on the information available to the node, which may result in being partial and possibly also stale".

If the default is undesired then the pre `1.4.0.Beta1` behaviour can be enabled, see: <<modules-discovery-zen,no-master-block>>
27 changes: 23 additions & 4 deletions docs/reference/modules/discovery/zen.asciidoc
Expand Up @@ -68,7 +68,7 @@ perform the discovery.
[[master-election]]
==== Master Election

As part of the initial ping process a master of the cluster is either
As part of the ping process a master of the cluster is either
elected or joined to. This is done automatically. The
`discovery.zen.ping_timeout` (which defaults to `3s`) allows to
configure the election to handle cases of slow or congested networks
Expand All @@ -77,15 +77,20 @@ will send a join request to the master (`discovery.zen.join_timeout`)
with a timeout defaulting at 20 times the ping timeout.
added[1.3.0,Previously defaulted to 10 times the ping timeout].

When the master node stops or has encountered a problem, the cluster nodes
start pinging again and will elect a new master. This pinging round also
serves as protection against (partial) network failures where node may unjustly
Copy link
Contributor

Choose a reason for hiding this comment

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

as a protection.

think that the master has failed. In this case the node will simply hear from
other nodes about the currently active master.

Nodes can be excluded from becoming a master by setting `node.master` to
`false`. Note, once a node is a client node (`node.client` set to
`true`), it will not be allowed to become a master (`node.master` is
automatically set to `false`).

The `discovery.zen.minimum_master_nodes` allows to control the minimum
number of master eligible nodes a node should "see" in order to operate
within the cluster. Its recommended to set it to a higher value than 1
when running more than 2 nodes in the cluster.
number of master eligible nodes a node should "see" in order to win master election.
Copy link
Contributor

Choose a reason for hiding this comment

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

win a master election..

Its recommended to set it to a higher value than 1 when running more than 2 nodes in the cluster.
Copy link
Contributor

Choose a reason for hiding this comment

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

we recommend setting it to a quorum of your master eligible nodes.


[float]
[[fault-detection]]
Expand Down Expand Up @@ -163,3 +168,17 @@ updates in the queue. The `discovery.zen.publish_timeout` is set by default
to 30 seconds and can be changed dynamically through the
<<cluster-update-settings,cluster update settings api>> added[1.1.0, The
setting existed before but wasn't dynamic].

[float]
[[no-master-block]]
==== No master block

coming[1.4.0.Beta1]

For a node to be fully operational, it must have an active master. The `discovery.zen.no_master_block` settings controls
what operations should be rejected when there is no active master.]
Copy link
Contributor

Choose a reason for hiding this comment

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

extra ']'?


The `discovery.zen.no_master_block` setting has two valid options:
* `all` - All operations on the node. I.e., both read & writes will be rejected.
Copy link
Contributor

Choose a reason for hiding this comment

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

Does this include read-only cluster-metadata APIs like Node Stats, Cluster State, etc? Should probably add a note regardless of what the answer is, just to be explicit.

* `write` - Write operations will be rejected. Read operations will succeed, based on the last known cluster configuration.
This may result in partial reads or stale data as this node may be isolated from the rest of the cluster. This is the default.