87 lines
3.6 KiB
Plaintext
87 lines
3.6 KiB
Plaintext
[float]
|
|
[[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[]
|
|
|
|
[float]
|
|
==== 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 <<discovery-settings,the discovery
|
|
settings summary>> for an example, and the
|
|
<<modules-discovery-bootstrap-cluster,cluster bootstrapping reference
|
|
documentation>> describes this setting in more detail.
|
|
|
|
The `discovery.zen.minimum_master_nodes` setting is permitted, but ignored, on
|
|
7.x nodes.
|
|
|
|
[float]
|
|
==== 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 <<modules-discovery-adding-removing-nodes,voting config exclusions API>>.
|
|
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.
|
|
|
|
[float]
|
|
==== 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`.
|
|
|
|
[float]
|
|
[[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.
|
|
|
|
[float]
|
|
==== Reduced default timeouts for fault detection
|
|
|
|
By default the <<cluster-fault-detection,cluster fault detection>> 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.
|
|
|
|
[float]
|
|
==== 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
|
|
<<modules-discovery-hosts-providers,`discovery.seed_hosts` or another seed
|
|
hosts provider>> to provide the addresses of all the master-eligible nodes in
|
|
your cluster.
|