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
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -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. | ||
|
||
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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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>> |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -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 | ||
|
@@ -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 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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]] | ||
|
@@ -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.] | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. |
There was a problem hiding this comment.
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".