2018-12-21 14:24:48 -05:00
|
|
|
[[modules-discovery-settings]]
|
|
|
|
=== Discovery and cluster formation settings
|
|
|
|
|
|
|
|
Discovery and cluster formation are affected by the following settings:
|
|
|
|
|
2019-02-06 06:34:38 -05:00
|
|
|
`discovery.seed_hosts`::
|
|
|
|
|
|
|
|
Provides a list of master-eligible nodes in the cluster. Each value has the
|
|
|
|
format `host:port` or `host`, where `port` defaults to the setting
|
|
|
|
`transport.profiles.default.port`. Note that IPv6 hosts must be bracketed.
|
|
|
|
The default value is `["127.0.0.1", "[::1]"]`. See <<unicast.hosts>>. This
|
|
|
|
setting was previously known as `discovery.zen.ping.unicast.hosts`. Its old
|
|
|
|
name is deprecated but continues to work in order to preserve backwards
|
|
|
|
compatibility. Support for the old name will be removed in a future
|
|
|
|
version.
|
|
|
|
|
|
|
|
`discovery.seed_providers`::
|
|
|
|
|
|
|
|
Specifies which types of <<built-in-hosts-providers,seed hosts provider>>
|
|
|
|
to use to obtain the addresses of the seed nodes used to start the
|
|
|
|
discovery process. By default, it is the
|
|
|
|
<<settings-based-hosts-provider,settings-based seed hosts provider>>. This
|
|
|
|
setting was previously known as `discovery.zen.hosts_provider`. Its old
|
|
|
|
name is deprecated but continues to work in order to preserve backwards
|
|
|
|
compatibility. Support for the old name will be removed in a future
|
|
|
|
version.
|
2019-06-05 15:29:40 -04:00
|
|
|
|
|
|
|
`discovery.type`::
|
|
|
|
|
|
|
|
Specifies whether {es} should form a multiple-node cluster. By default, {es}
|
|
|
|
discovers other nodes when forming a cluster and allows other nodes to join
|
|
|
|
the cluster later. If `discovery.type` is set to `single-node`, {es} forms a
|
|
|
|
single-node cluster. For more information about when you might use this
|
|
|
|
setting, see <<single-node-discovery>>.
|
2019-02-06 06:34:38 -05:00
|
|
|
|
2019-04-15 14:22:10 -04:00
|
|
|
`cluster.initial_master_nodes`::
|
|
|
|
|
2019-06-05 15:29:40 -04:00
|
|
|
Sets the initial set of master-eligible nodes in a brand-new cluster. By
|
|
|
|
default this list is empty, meaning that this node expects to join a cluster
|
|
|
|
that has already been bootstrapped. See <<initial_master_nodes>>.
|
|
|
|
|
2019-04-15 14:22:10 -04:00
|
|
|
[float]
|
|
|
|
==== Expert settings
|
|
|
|
|
|
|
|
Discovery and cluster formation are also affected by the following
|
|
|
|
_expert-level_ settings, although it is not recommended to change any of these
|
|
|
|
from their default values.
|
|
|
|
|
2019-05-15 09:26:04 -04:00
|
|
|
WARNING: If you adjust these settings then your cluster may not form correctly
|
2019-04-15 14:22:10 -04:00
|
|
|
or may become unstable or intolerant of certain failures.
|
|
|
|
|
2019-02-06 06:34:38 -05:00
|
|
|
`discovery.cluster_formation_warning_timeout`::
|
|
|
|
|
|
|
|
Sets how long a node will try to form a cluster before logging a warning
|
|
|
|
that the cluster did not form. Defaults to `10s`. If a cluster has not
|
|
|
|
formed after `discovery.cluster_formation_warning_timeout` has elapsed then
|
|
|
|
the node will log a warning message that starts with the phrase `master not
|
|
|
|
discovered` which describes the current state of the discovery process.
|
|
|
|
|
|
|
|
`discovery.find_peers_interval`::
|
|
|
|
|
|
|
|
Sets how long a node will wait before attempting another discovery round.
|
|
|
|
Defaults to `1s`.
|
|
|
|
|
|
|
|
`discovery.probe.connect_timeout`::
|
|
|
|
|
|
|
|
Sets how long to wait when attempting to connect to each address. Defaults
|
|
|
|
to `3s`.
|
|
|
|
|
|
|
|
`discovery.probe.handshake_timeout`::
|
|
|
|
|
|
|
|
Sets how long to wait when attempting to identify the remote node via a
|
|
|
|
handshake. Defaults to `1s`.
|
|
|
|
|
|
|
|
`discovery.request_peers_timeout`::
|
2019-04-15 14:22:10 -04:00
|
|
|
|
2019-02-06 06:34:38 -05:00
|
|
|
Sets how long a node will wait after asking its peers again before
|
|
|
|
considering the request to have failed. Defaults to `3s`.
|
|
|
|
|
|
|
|
`discovery.seed_resolver.max_concurrent_resolvers`::
|
|
|
|
|
|
|
|
Specifies how many concurrent DNS lookups to perform when resolving the
|
|
|
|
addresses of seed nodes. Defaults to `10`. This setting was previously
|
|
|
|
known as `discovery.zen.ping.unicast.concurrent_connects`. Its old name is
|
|
|
|
deprecated but continues to work in order to preserve backwards
|
|
|
|
compatibility. Support for the old name will be removed in a future
|
|
|
|
version.
|
|
|
|
|
|
|
|
`discovery.seed_resolver.timeout`::
|
|
|
|
|
|
|
|
Specifies how long to wait for each DNS lookup performed when resolving the
|
|
|
|
addresses of seed nodes. Defaults to `5s`. This setting was previously
|
|
|
|
known as `discovery.zen.ping.unicast.hosts.resolve_timeout`. Its old name
|
|
|
|
is deprecated but continues to work in order to preserve backwards
|
|
|
|
compatibility. Support for the old name will be removed in a future
|
|
|
|
version.
|
|
|
|
|
2019-01-07 12:11:14 -05:00
|
|
|
`cluster.auto_shrink_voting_configuration`::
|
|
|
|
|
|
|
|
Controls whether the <<modules-discovery-voting,voting configuration>>
|
|
|
|
sheds departed nodes automatically, as long as it still contains at least 3
|
|
|
|
nodes. The default value is `true`. If set to `false`, the voting
|
|
|
|
configuration never shrinks automatically and you must remove departed
|
|
|
|
nodes manually with the <<voting-config-exclusions,voting configuration
|
|
|
|
exclusions API>>.
|
|
|
|
|
2018-12-21 14:24:48 -05:00
|
|
|
[[master-election-settings]]`cluster.election.back_off_time`::
|
|
|
|
|
|
|
|
Sets the amount to increase the upper bound on the wait before an election
|
|
|
|
on each election failure. Note that this is _linear_ backoff. This defaults
|
2019-04-15 14:22:10 -04:00
|
|
|
to `100ms`. Changing this setting from the default may cause your cluster
|
|
|
|
to fail to elect a master node.
|
2018-12-21 14:24:48 -05:00
|
|
|
|
|
|
|
`cluster.election.duration`::
|
|
|
|
|
2019-04-15 14:22:10 -04:00
|
|
|
Sets how long each election is allowed to take before a node considers it
|
|
|
|
to have failed and schedules a retry. This defaults to `500ms`. Changing
|
|
|
|
this setting from the default may cause your cluster to fail to elect a
|
|
|
|
master node.
|
2019-02-06 06:34:38 -05:00
|
|
|
|
2018-12-21 14:24:48 -05:00
|
|
|
`cluster.election.initial_timeout`::
|
|
|
|
|
|
|
|
Sets the upper bound on how long a node will wait initially, or after the
|
|
|
|
elected master fails, before attempting its first election. This defaults
|
2019-04-15 14:22:10 -04:00
|
|
|
to `100ms`. Changing this setting from the default may cause your cluster
|
|
|
|
to fail to elect a master node.
|
2019-02-06 06:34:38 -05:00
|
|
|
|
2018-12-21 14:24:48 -05:00
|
|
|
`cluster.election.max_timeout`::
|
|
|
|
|
|
|
|
Sets the maximum upper bound on how long a node will wait before attempting
|
|
|
|
an first election, so that an network partition that lasts for a long time
|
2019-04-15 14:22:10 -04:00
|
|
|
does not result in excessively sparse elections. This defaults to `10s`.
|
|
|
|
Changing this setting from the default may cause your cluster to fail to
|
|
|
|
elect a master node.
|
2019-02-06 06:34:38 -05:00
|
|
|
|
2018-12-21 14:24:48 -05:00
|
|
|
[[fault-detection-settings]]`cluster.fault_detection.follower_check.interval`::
|
|
|
|
|
|
|
|
Sets how long the elected master waits between follower checks to each
|
2019-04-15 14:22:10 -04:00
|
|
|
other node in the cluster. Defaults to `1s`. Changing this setting from the
|
|
|
|
default may cause your cluster to become unstable.
|
2018-12-21 14:24:48 -05:00
|
|
|
|
|
|
|
`cluster.fault_detection.follower_check.timeout`::
|
|
|
|
|
|
|
|
Sets how long the elected master waits for a response to a follower check
|
2019-04-15 14:22:10 -04:00
|
|
|
before considering it to have failed. Defaults to `10s`. Changing this
|
|
|
|
setting from the default may cause your cluster to become unstable.
|
2018-12-21 14:24:48 -05:00
|
|
|
|
|
|
|
`cluster.fault_detection.follower_check.retry_count`::
|
|
|
|
|
|
|
|
Sets how many consecutive follower check failures must occur to each node
|
|
|
|
before the elected master considers that node to be faulty and removes it
|
2019-04-15 14:22:10 -04:00
|
|
|
from the cluster. Defaults to `3`. Changing this setting from the default
|
|
|
|
may cause your cluster to become unstable.
|
2018-12-21 14:24:48 -05:00
|
|
|
|
|
|
|
`cluster.fault_detection.leader_check.interval`::
|
|
|
|
|
|
|
|
Sets how long each node waits between checks of the elected master.
|
2019-04-15 14:22:10 -04:00
|
|
|
Defaults to `1s`. Changing this setting from the default may cause your
|
|
|
|
cluster to become unstable.
|
2018-12-21 14:24:48 -05:00
|
|
|
|
|
|
|
`cluster.fault_detection.leader_check.timeout`::
|
|
|
|
|
|
|
|
Sets how long each node waits for a response to a leader check from the
|
2019-02-04 09:11:12 -05:00
|
|
|
elected master before considering it to have failed. Defaults to `10s`.
|
2019-04-15 14:22:10 -04:00
|
|
|
Changing this setting from the default may cause your cluster to become
|
|
|
|
unstable.
|
2018-12-21 14:24:48 -05:00
|
|
|
|
|
|
|
`cluster.fault_detection.leader_check.retry_count`::
|
|
|
|
|
|
|
|
Sets how many consecutive leader check failures must occur before a node
|
|
|
|
considers the elected master to be faulty and attempts to find or elect a
|
2019-04-15 14:22:10 -04:00
|
|
|
new master. Defaults to `3`. Changing this setting from the default may
|
|
|
|
cause your cluster to become unstable.
|
2018-12-21 14:24:48 -05:00
|
|
|
|
|
|
|
`cluster.follower_lag.timeout`::
|
|
|
|
|
|
|
|
Sets how long the master node waits to receive acknowledgements for cluster
|
2019-04-15 14:22:10 -04:00
|
|
|
state updates from lagging nodes. The default value is `90s`. If a node
|
|
|
|
does not successfully apply the cluster state update within this period of
|
|
|
|
time, it is considered to have failed and is removed from the cluster. See
|
2019-02-06 06:34:38 -05:00
|
|
|
<<cluster-state-publishing>>.
|
2018-12-21 14:24:48 -05:00
|
|
|
|
|
|
|
`cluster.join.timeout`::
|
|
|
|
|
|
|
|
Sets how long a node will wait after sending a request to join a cluster
|
|
|
|
before it considers the request to have failed and retries. Defaults to
|
|
|
|
`60s`.
|
2019-02-06 06:34:38 -05:00
|
|
|
|
2018-12-21 14:24:48 -05:00
|
|
|
`cluster.max_voting_config_exclusions`::
|
|
|
|
|
|
|
|
Sets a limit on the number of voting configuration exclusions at any one
|
|
|
|
time. The default value is `10`. See
|
|
|
|
<<modules-discovery-adding-removing-nodes>>.
|
2019-02-06 06:34:38 -05:00
|
|
|
|
2019-08-01 03:21:40 -04:00
|
|
|
`cluster.publish.info_timeout`::
|
|
|
|
|
|
|
|
Sets how long the master node waits for each cluster state update to be
|
|
|
|
completely published to all nodes before logging a message indicating that
|
|
|
|
some nodes are responding slowly. The default value is `10s`.
|
|
|
|
|
2019-02-06 06:34:38 -05:00
|
|
|
`cluster.publish.timeout`::
|
|
|
|
|
2018-12-21 14:24:48 -05:00
|
|
|
Sets how long the master node waits for each cluster state update to be
|
2019-04-15 14:22:10 -04:00
|
|
|
completely published to all nodes. The default value is `30s`. See
|
2019-02-06 06:34:38 -05:00
|
|
|
<<cluster-state-publishing>>.
|
2018-12-21 14:24:48 -05:00
|
|
|
|
2019-02-05 03:47:56 -05:00
|
|
|
[[no-master-block]]`cluster.no_master_block`::
|
2018-12-21 14:24:48 -05:00
|
|
|
Specifies which operations are rejected when there is no active master in a
|
|
|
|
cluster. This setting has two valid values:
|
|
|
|
+
|
|
|
|
--
|
|
|
|
`all`::: All operations on the node (both read and write operations) are rejected.
|
|
|
|
This also applies for API cluster state read or write operations, like the get
|
|
|
|
index settings, put mapping and cluster state API.
|
|
|
|
|
|
|
|
`write`::: (default) Write operations are rejected. Read operations succeed,
|
|
|
|
based on the last known cluster configuration. This situation may result in
|
|
|
|
partial reads of stale data as this node may be isolated from the rest of the
|
|
|
|
cluster.
|
|
|
|
|
|
|
|
[NOTE]
|
|
|
|
===============================
|
2019-02-05 03:47:56 -05:00
|
|
|
* The `cluster.no_master_block` setting doesn't apply to nodes-based APIs
|
2018-12-21 14:24:48 -05:00
|
|
|
(for example, cluster stats, node info, and node stats APIs). Requests to these
|
|
|
|
APIs are not be blocked and can run on any available node.
|
2019-02-06 06:34:38 -05:00
|
|
|
|
2018-12-21 14:24:48 -05:00
|
|
|
* For the cluster to be fully operational, it must have an active master.
|
|
|
|
===============================
|
2019-02-05 03:47:56 -05:00
|
|
|
|
|
|
|
WARNING: This setting replaces the `discovery.zen.no_master_block` setting in
|
|
|
|
earlier versions. The `discovery.zen.no_master_block` setting is ignored.
|
|
|
|
|
2018-12-21 14:24:48 -05:00
|
|
|
--
|