123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301 |
- [discrete]
- [[breaking_80_settings_changes]]
- ==== Settings 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[]
- [[search-remote-settings-removed]]
- .The `search.remote.*` settings have been removed.
- [%collapsible]
- ====
- *Details* +
- In 6.5 these settings were deprecated in favor of `cluster.remote`. In 7.x we
- provided automatic upgrading of these settings to their `cluster.remote`
- counterparts. In 8.0.0, these settings have been removed. Elasticsearch will
- refuse to start if you have these settings in your configuration or cluster
- state.
- *Impact* +
- Use the replacement `cluster.remote` settings. Discontinue use of the
- `search.remote.*` settings. Specifying these settings in `elasticsearch.yml`
- will result in an error on startup.
- ====
- [[remove-pidfile]]
- .The `pidfile` setting has been replaced by `node.pidfile`.
- [%collapsible]
- ====
- *Details* +
- To ensure that all settings are in a proper namespace, the `pidfile` setting was
- previously deprecated in version 7.4.0 of Elasticsearch, and is removed in
- version 8.0.0. Instead, use `node.pidfile`.
- *Impact* +
- Use the `node.pidfile` setting. Discontinue use of the `pidfile` setting.
- Specifying the `pidfile` setting in `elasticsearch.yml` will result in an error
- on startup.
- ====
- [[remove-processors]]
- .The `processors` setting has been replaced by `node.processors`.
- [%collapsible]
- ====
- *Details* +
- To ensure that all settings are in a proper namespace, the `processors` setting
- was previously deprecated in version 7.4.0 of Elasticsearch, and is removed in
- version 8.0.0. Instead, use `node.processors`.
- *Impact* +
- Use the `node.processors` setting. Discontinue use of the `processors` setting.
- Specifying the `processors` setting in `elasticsearch.yml` will result in an
- error on startup.
- ====
- .The `node.processors` setting can no longer exceed the available number of processors.
- [%collapsible]
- ====
- *Details* +
- Previously it was possible to set the number of processors used to set the
- default sizes for the thread pools to be more than the number of available
- processors. As this leads to more context switches and more threads but without
- an increase in the number of physical CPUs on which to schedule these additional
- threads, the `node.processors` setting is now bounded by the number of available
- processors.
- *Impact* +
- If specified, ensure the value of `node.processors` setting does not exceed the
- number of available processors. Setting the `node.processors` value greater than
- the number of available processors in `elasticsearch.yml` will result in an
- error on startup.
- ====
- .The `cluster.remote.connect` setting has been removed.
- [%collapsible]
- ====
- *Details* +
- In Elasticsearch 7.7.0, the setting `cluster.remote.connect` was deprecated in
- favor of setting `node.remote_cluster_client`. In Elasticsearch 8.0.0, the
- setting `cluster.remote.connect` is removed.
- *Impact* +
- Use the `node.remote_cluster_client` setting. Discontinue use of the
- `cluster.remote.connect` setting. Specifying the `cluster.remote.connect`
- setting in `elasticsearch.yml` will result in an error on startup.
- ====
- .The `node.local_storage` setting has been removed.
- [%collapsible]
- ====
- *Details* +
- In Elasticsearch 7.8.0, the setting `node.local_storage` was deprecated and
- beginning in Elasticsearch 8.0.0 all nodes will require local storage. Therefore,
- the `node.local_storage` setting has been removed.
- *Impact* +
- Discontinue use of the `node.local_storage` setting. Specifying this setting in
- `elasticsearch.yml` will result in an error on startup.
- ====
- .The `auth.password` setting for HTTP monitoring has been removed.
- [%collapsible]
- ====
- *Details* +
- In Elasticsearch 7.7.0, the setting `xpack.monitoring.exporters.<exporterName>.auth.password`
- was deprecated in favor of setting `xpack.monitoring.exporters.<exporterName>.auth.secure_password`.
- In Elasticsearch 8.0.0, the setting `xpack.monitoring.exporters.<exporterName>.auth.password` is
- removed.
- *Impact* +
- Use the `xpack.monitoring.exporters.<exporterName>.auth.secure_password`
- setting. Discontinue use of the
- `xpack.monitoring.exporters.<exporterName>.auth.password` setting. Specifying
- the `xpack.monitoring.exporters.<exporterName>.auth.password` setting in
- `elasticsearch.yml` will result in an error on startup.
- ====
- .Settings used to disable basic license features have been removed.
- [%collapsible]
- ====
- *Details* +
- The following settings were deprecated in {es} 7.8.0 and have been removed
- in {es} 8.0.0:
- * `xpack.enrich.enabled`
- * `xpack.flattened.enabled`
- * `xpack.ilm.enabled`
- * `xpack.monitoring.enabled`
- * `xpack.rollup.enabled`
- * `xpack.slm.enabled`
- * `xpack.sql.enabled`
- * `xpack.transform.enabled`
- * `xpack.vectors.enabled`
- These basic license features are now always enabled.
- If you have disabled ILM so that you can use another tool to manage Watcher
- indices, the newly introduced `xpack.watcher.use_ilm_index_management` setting
- may be set to false.
- *Impact* +
- Discontinue use of the removed settings. Specifying these settings in
- `elasticsearch.yml` will result in an error on startup.
- ====
- .Settings used to defer cluster recovery pending a certain number of master nodes have been removed.
- [%collapsible]
- ====
- *Details* +
- The following settings were deprecated in {es} 7.8.0 and have been removed in
- {es} 8.0.0:
- * `gateway.expected_nodes`
- * `gateway.expected_master_nodes`
- * `gateway.recover_after_nodes`
- * `gateway.recover_after_master_nodes`
- It is safe to recover the cluster as soon as a majority of master-eligible
- nodes have joined so there is no benefit in waiting for any additional
- master-eligible nodes to start.
- *Impact* +
- Discontinue use of the removed settings. If needed, use
- `gateway.expected_data_nodes` or `gateway.recover_after_data_nodes` to defer
- cluster recovery pending a certain number of data nodes.
- ====
- .You can no longer set `xpack.searchable.snapshot.shared_cache.size` on non-frozen nodes.
- [%collapsible]
- ====
- *Details* +
- Setting `xpack.searchable.snapshot.shared_cache.size` to be positive on a node
- that does not have the `data_frozen` role was deprecated in {es} 7.12.0 and has
- been removed in {es} 8.0.0.
- *Impact* +
- {es} only allocates partially mounted indices to nodes with the `data_frozen`
- role. Do not set `xpack.searchable.snapshot.shared_cache.size` on nodes without
- the `data_frozen` role. Removing the setting on nodes without the `data_frozen`
- role will not impact functionality.
- ====
- .By default, destructive index actions do not allow wildcards.
- [%collapsible]
- ====
- *Details* +
- The default value of the setting `action.destructive_requires_name` changes from `false`
- to `true` in {es} 8.0.0.
- In previous versions, the default setting allowed users to use wildcard
- patterns to delete, close, or change index blocks on indices. In order
- to prevent the accidental deletion of indices that happen to match a
- wildcard pattern, we now require, by default, that any such destructive
- operation explicitly name the indices it intends to modify.
- *Impact* +
- If you would like to use wildcard patterns for destructive actions, set
- `action.destructive_requires_name` to `false` using the <<cluster-update-settings,
- cluster settings>> API.
- ====
- .Legacy role settings have been removed.
- [%collapsible]
- ====
- *Details* +
- The legacy role settings:
- * `node.data`
- * `node.ingest`
- * `node.master`
- * `node.ml`
- * `node.remote_cluster_client`
- * `node.transform`
- * `node.voting_only`
- have been removed. Instead, use the `node.roles` setting. If you were previously
- using the legacy role settings on a 7.13 or later cluster, you will have a
- deprecation log message on each of your nodes indicating the exact replacement
- value for `node.roles`.
- *Impact* +
- Discontinue use of the removed settings. Specifying these settings in
- `elasticsearch.yml` will result in an error on startup.
- ====
- [[system-call-filter-setting]]
- .System call filter setting removed
- [%collapsible]
- ====
- *Details* +
- Elasticsearch uses system call filters to remove its ability to fork another
- process. This is useful to mitigate remote code exploits. These system call
- filters are enabled by default, and were previously controlled via the setting
- `bootstrap.system_call_filter`. Starting in Elasticsearch 8.0, system call
- filters will be required. As such, the setting `bootstrap.system_call_filter`
- was deprecated in Elasticsearch 7.13.0, and is removed as of Elasticsearch
- 8.0.0.
- *Impact* +
- Discontinue use of the removed setting. Specifying this setting in Elasticsearch
- configuration will result in an error on startup.
- ====
- [[tier-filter-setting]]
- .Tier filtering settings removed
- [%collapsible]
- ====
- *Details* +
- The cluster and index level settings ending in `._tier` used for filtering the allocation of a shard
- to a particular set of nodes have been removed. Instead, the <<tier-preference-allocation-filter,
- tier preference setting>>, `index.routing.allocation.include._tier_preference` should be used. The
- removed settings are:
- Cluster level settings:
- - `cluster.routing.allocation.include._tier`
- - `cluster.routing.allocation.exclude._tier`
- - `cluster.routing.allocation.require._tier`
- Index settings:
- - `index.routing.allocation.include._tier`
- - `index.routing.allocation.exclude._tier`
- - `index.routing.allocation.require._tier`
- *Impact* +
- Discontinue use of the removed settings. Specifying any of these cluster settings in Elasticsearch
- configuration will result in an error on startup. Any indices using these settings will have the
- settings archived (and they will have no effect) when the index metadata is loaded.
- [[shared-data-path-setting]]
- .Shared data path and per index data path settings deprecated
- [%collapsible]
- ====
- *Details* +
- Elasticsearch uses the shared data path as the base path of per index data
- paths. This feature was previously used with shared replicas. Starting in
- 7.13.0, these settings are deprecated. Starting in 8.0 only existing
- indices created in 7.x will be capable of using the shared data path and
- per index data path settings.
- *Impact* +
- Discontinue use of the deprecated settings.
- [[single-data-node-watermark-setting]]
- .Single data node watermark setting only accept true and is deprecated
- [%collapsible]
- ====
- *Details* +
- In 7.14, setting `cluster.routing.allocation.disk.watermark.enable_for_single_data_node`
- to false was deprecated. Starting in 8.0, the only legal value will be
- true. In a future release, the setting will be removed completely, with same
- behavior as if the setting was `true`.
- If the old behavior is desired for a single data node cluster, disk based
- allocation can be disabled by setting
- `cluster.routing.allocation.disk.threshold_enabled: false`
- *Impact* +
- Discontinue use of the deprecated setting.
- ====
|