From fca406415d6c4f3381ad98c3a4b593426e48868c Mon Sep 17 00:00:00 2001 From: Martijn van Groningen Date: Mon, 15 Sep 2014 10:00:28 +0200 Subject: [PATCH] Docs: Document the most important changes to zen discovery. Closes #7746 --- docs/reference/migration/migrate_1_x.asciidoc | 8 +++++ docs/reference/modules/discovery/zen.asciidoc | 34 ++++++++++++++++--- 2 files changed, 38 insertions(+), 4 deletions(-) diff --git a/docs/reference/migration/migrate_1_x.asciidoc b/docs/reference/migration/migrate_1_x.asciidoc index 6c95255693e..1216012ea4c 100644 --- a/docs/reference/migration/migrate_1_x.asciidoc +++ b/docs/reference/migration/migrate_1_x.asciidoc @@ -71,4 +71,12 @@ 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 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 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: <> \ No newline at end of file diff --git a/docs/reference/modules/discovery/zen.asciidoc b/docs/reference/modules/discovery/zen.asciidoc index 3ee6850018e..2f2d0ab9f72 100644 --- a/docs/reference/modules/discovery/zen.asciidoc +++ b/docs/reference/modules/discovery/zen.asciidoc @@ -68,22 +68,30 @@ 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 for the tweaking of election time to handle cases of slow or congested networks (higher values assure less chance of failure). Once a node joins, it will send a join request to the master (`discovery.zen.join_timeout`) with a timeout defaulting at 20 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 a protection against (partial) network failures where node may unjustly +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` sets 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 a master election. +It must be set to a quorum of your master eligible nodes. It is recommended to avoid +having only two master eligible nodes, since a quorum of two is two. Therefore, a loss +of either master node will result in an inoperable cluster [float] [[fault-detection]] @@ -160,3 +168,21 @@ all nodes to respond, up to a timeout, before going ahead processing the next updates in the queue. The `discovery.zen.publish_timeout` is set by default to 30 seconds and can be changed dynamically through the <> + +[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. + +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. This also applies for api cluster state +read or write operations, like the get index settings, put mapping and cluster state api. +* `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. + +The `discovery.zen.no_master_block` setting doesn't apply for nodes based apis (for example cluster stats, node info and +node stats apis) which will not be blocked and try to execute on any node possible. \ No newline at end of file