123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168 |
- [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.
- ====
|