IMPORTANT: No additional bug fixes or documentation updates will be released for this version. For the latest information, see the current release documentation.

« Cluster fault detection Shard allocation and cluster-level routing »

› › ›

Discovery and cluster formation settings

edit

Discovery and cluster formation settings

edit

Discovery and cluster formation are affected by the following settings:

discovery.seed_hosts

Provides a list of the addresses of the master-eligible nodes in the cluster. May also be a single string containing the addresses separated by commas. Each address has the format host:port or host. The host is either a host name to be resolved by DNS, an IPv4 address, or an IPv6 address. IPv6 addresses must be enclosed in square brackets. If a host name resolves via DNS to multiple addresses, Elasticsearch uses all of them. DNS lookups are subject to JVM DNS caching. If the port is not given then it is determined by checking the following settings in order:

transport.profiles.default.port
transport.port

If neither of these is set then the default port is 9300. The default value for discovery.seed_hosts is ["127.0.0.1", "[::1]"]. See discovery.seed_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 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 seed hosts provider which obtains the seed node addresses from the discovery.seed_hosts setting. 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.

discovery.type

Specifies whether Elasticsearch should form a multiple-node cluster. By default, Elasticsearch discovers other nodes when forming a cluster and allows other nodes to join the cluster later. If discovery.type is set to single-node, Elasticsearch forms a single-node cluster. For more information about when you might use this setting, see Single-node discovery.

cluster.initial_master_nodes

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 cluster.initial_master_nodes.

Expert settings

edit

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.

If you adjust these settings then your cluster may not form correctly or may become unstable or intolerant of certain failures.

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.request_peers_timeout

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.

cluster.auto_shrink_voting_configuration

Controls whether the 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 configuration exclusions API.

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 to 100ms. Changing this setting from the default may cause your cluster to fail to elect a master node.

cluster.election.duration

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.

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 to 100ms. Changing this setting from the default may cause your cluster to fail to elect a master node.

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 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.

cluster.fault_detection.follower_check.interval

Sets how long the elected master waits between follower checks to each other node in the cluster. Defaults to 1s. Changing this setting from the default may cause your cluster to become unstable.

cluster.fault_detection.follower_check.timeout

Sets how long the elected master waits for a response to a follower check before considering it to have failed. Defaults to 10s. Changing this setting from the default may cause your cluster to become unstable.

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 from the cluster. Defaults to 3. Changing this setting from the default may cause your cluster to become unstable.

cluster.fault_detection.leader_check.interval

Sets how long each node waits between checks of the elected master. Defaults to 1s. Changing this setting from the default may cause your cluster to become unstable.

cluster.fault_detection.leader_check.timeout

Sets how long each node waits for a response to a leader check from the elected master before considering it to have failed. Defaults to 10s. Changing this setting from the default may cause your cluster to become unstable.

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 new master. Defaults to 3. Changing this setting from the default may cause your cluster to become unstable.

cluster.follower_lag.timeout

Sets how long the master node waits to receive acknowledgements for cluster 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 Publishing the cluster state.

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.

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 Adding and removing nodes.

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.

cluster.publish.timeout

Sets how long the master node waits for each cluster state update to be completely published to all nodes. The default value is 30s. See Publishing the cluster state.

cluster.no_master_block

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.

The cluster.no_master_block setting doesn’t apply to nodes-based APIs (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.
For the cluster to be fully operational, it must have an active master.

This setting replaces the discovery.zen.no_master_block setting in earlier versions. The discovery.zen.no_master_block setting is ignored.

« Cluster fault detection Shard allocation and cluster-level routing »