2018-12-20 08:02:44 -05:00
|
|
|
[float]
|
|
|
|
|
[[breaking_70_discovery_changes]]
|
|
|
|
|
=== Discovery changes
|
|
|
|
|
|
2019-04-08 21:54:29 -04:00
|
|
|
//NOTE: The notable-breaking-changes tagged regions are re-used in the
|
|
|
|
|
//Installation and Upgrade Guide
|
|
|
|
|
|
|
|
|
|
//tag::notable-breaking-changes[]
|
|
|
|
|
|
|
|
|
|
// end::notable-breaking-changes[]
|
|
|
|
|
|
2018-12-20 08:02:44 -05:00
|
|
|
[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.
|
|
|
|
|
|
2019-01-30 15:09:15 -05:00
|
|
|
The `discovery.zen.minimum_master_nodes` setting is permitted, but ignored, on
|
|
|
|
|
7.x nodes.
|
2018-12-20 08:02:44 -05:00
|
|
|
|
|
|
|
|
[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:
|
|
|
|
|
|
2019-02-05 03:46:52 -05:00
|
|
|
- `discovery.seed_hosts`
|
|
|
|
|
- `discovery.seed_providers`
|
2018-12-20 08:02:44 -05:00
|
|
|
- `cluster.initial_master_nodes`
|
2019-03-27 11:56:02 -04:00
|
|
|
- `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`.
|
2019-02-05 03:47:56 -05:00
|
|
|
|
|
|
|
|
[float]
|
|
|
|
|
==== 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.
|
2019-03-20 11:49:50 -04:00
|
|
|
|
|
|
|
|
[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.
|
