[discrete] [[breaking_70_discovery_changes]] === Discovery changes //NOTE: The notable-breaking-changes tagged regions are re-used in the //Installation and Upgrade Guide //tag::notable-breaking-changes[] // end::notable-breaking-changes[] [discrete] ==== Cluster bootstrapping is required if discovery is configured The first time a cluster is started, `cluster.initial_master_nodes` must be set to perform cluster bootstrapping. It should contain the names of the master-eligible nodes in the initial cluster and be defined on every master-eligible node in the cluster. See <> for an example, and the <> describes this setting in more detail. The `discovery.zen.minimum_master_nodes` setting is permitted, but ignored, on 7.x nodes. [discrete] ==== Removing master-eligible nodes sometimes requires voting exclusions If you wish to remove half or more of the master-eligible nodes from a cluster, you must first exclude the affected nodes from the voting configuration using the <>. If you remove fewer than half of the master-eligible nodes at the same time, voting exclusions are not required. If you remove only master-ineligible nodes such as data-only nodes or coordinating-only nodes, voting exclusions are not required. Likewise, if you add nodes to the cluster, voting exclusions are not required. [discrete] ==== Discovery configuration is required in production Production deployments of Elasticsearch now require at least one of the following settings to be specified in the `elasticsearch.yml` configuration file: - `discovery.seed_hosts` - `discovery.seed_providers` - `cluster.initial_master_nodes` - `discovery.zen.ping.unicast.hosts` - `discovery.zen.hosts_provider` The first three settings in this list are only available in versions 7.0 and above. If you are preparing to upgrade from an earlier version, you must set `discovery.zen.ping.unicast.hosts` or `discovery.zen.hosts_provider`. [discrete] [[new-name-no-master-block-setting]] ==== New name for `no_master_block` setting The `discovery.zen.no_master_block` setting is now known as `cluster.no_master_block`. Any value set for `discovery.zen.no_master_block` is now ignored. You should remove this setting and, if needed, set `cluster.no_master_block` appropriately after the upgrade. [discrete] ==== Reduced default timeouts for fault detection By default the <> subsystem now considers a node to be faulty if it fails to respond to 3 consecutive pings, each of which times out after 10 seconds. Thus a node that is unresponsive for longer than 30 seconds is liable to be removed from the cluster. Previously the default timeout for each ping was 30 seconds, so that an unresponsive node might be kept in the cluster for over 90 seconds. [discrete] ==== Master-ineligible nodes are ignored by discovery In earlier versions it was possible to use master-ineligible nodes during the discovery process, either as seed nodes or to transfer discovery gossip indirectly between the master-eligible nodes. Clusters that relied on master-ineligible nodes like this were fragile and unable to automatically recover from some kinds of failure. Discovery now involves only the master-eligible nodes in the cluster so that it is not possible to rely on master-ineligible nodes like this. You should configure <> to provide the addresses of all the master-eligible nodes in your cluster.