mirror of
https://github.com/honeymoose/OpenSearch.git
synced 2025-03-09 14:34:43 +00:00
In 5.0 we don't allow index settings to be specified on the node level ie. in yaml files or via commandline argument. This can cause problems during upgrade if this was used extensively. For instance if analyzers where specified on a node level this might cause the index to be closed when imported (see #17187). In such a case all indices relying on this must be updated via `PUT /${index}/_settings`. Yet, this API has slightly different semantics since it overrides existing settings. To make this less painful this change adds a `preserve_existing` parameter on that API to ensure we have the same semantics as if the setting was applied on the node level. This change also adds a better error message and a change to the migration guide to ensure upgrades are smooth if index settings are specified on the node level. If a index setting is detected this change fails the node startup and prints a message like this: ``` ************************************************************************************* Found index level settings on node level configuration. Since elasticsearch 5.x index level settings can NOT be set on the nodes configuration like the elasticsearch.yaml, in system properties or command line arguments.In order to upgrade all indices the settings must be updated via the /${index}/_settings API. Unless all settings are dynamic all indices must be closed in order to apply the upgradeIndices created in the future should use index templates to set default values. Please ensure all required values are updated on all indices by executing: curl -XPUT 'http://localhost:9200/_all/_settings?preserve_existing=true' -d '{ "index.number_of_shards" : "1", "index.query.default_field" : "main_field", "index.translog.durability" : "async", "index.ttl.disable_purge" : "true" }' ************************************************************************************* ```
204 lines
8.9 KiB
Plaintext
204 lines
8.9 KiB
Plaintext
[[breaking_50_settings_changes]]
|
|
=== Settings changes
|
|
|
|
From Elasticsearch 5.0 on all settings are validated before they are applied.
|
|
Node level and default index level settings are validated on node startup,
|
|
dynamic cluster and index setting are validated before they are updated/added
|
|
to the cluster state.
|
|
|
|
Every setting must be a *known* setting. All settings must have been
|
|
registered with the node or transport client they are used with. This implies
|
|
that plugins that define custom settings must register all of their settings
|
|
during plugin loading using the `SettingsModule#registerSettings(Setting)`
|
|
method.
|
|
|
|
==== Index Level Settings
|
|
|
|
In previous versions Elasticsearch allowed to specify index level setting
|
|
as _defaults_ on the node level, inside the `elasticsearch.yaml` file or even via
|
|
command-line parameters. From Elasticsearch 5.0 on only selected settings like
|
|
for instance `index.codec` can be set on the node level. All other settings must be
|
|
set on each individual index. To set default values on every index, index templates
|
|
should be used instead.
|
|
|
|
==== Node settings
|
|
|
|
The `name` setting has been removed and is replaced by `node.name`. Usage of
|
|
`-Dname=some_node_name` is not supported anymore.
|
|
|
|
==== Gateway settings
|
|
|
|
The `gateway.format` setting for configuring global and index state serialization
|
|
format has been removed. By default, `smile` is used as the format.
|
|
|
|
==== Transport Settings
|
|
|
|
All settings with a `netty` infix have been replaced by their already existing
|
|
`transport` synonyms. For instance `transport.netty.bind_host` is no longer
|
|
supported and should be replaced by the superseding setting
|
|
`transport.bind_host`.
|
|
|
|
==== Script mode settings
|
|
|
|
Previously script mode settings (e.g., "script.inline: true",
|
|
"script.engine.groovy.inline.aggs: false", etc.) accepted the values
|
|
`on`, `true`, `1`, and `yes` for enabling a scripting mode, and the
|
|
values `off`, `false`, `0`, and `no` for disabling a scripting mode.
|
|
The variants `on`, `1`, and `yes ` for enabling and `off`, `0`,
|
|
and `no` for disabling are no longer supported.
|
|
|
|
|
|
==== Security manager settings
|
|
|
|
The option to disable the security manager `security.manager.enabled` has been
|
|
removed. In order to grant special permissions to elasticsearch users must
|
|
edit the local Java Security Policy.
|
|
|
|
==== Network settings
|
|
|
|
The `_non_loopback_` value for settings like `network.host` would arbitrarily
|
|
pick the first interface not marked as loopback. Instead, specify by address
|
|
scope (e.g. `_local_,_site_` for all loopback and private network addresses)
|
|
or by explicit interface names, hostnames, or addresses.
|
|
|
|
==== Forbid changing of thread pool types
|
|
|
|
Previously, <<modules-threadpool,thread pool types>> could be dynamically
|
|
adjusted. The thread pool type effectively controls the backing queue for the
|
|
thread pool and modifying this is an expert setting with minimal practical
|
|
benefits and high risk of being misused. The ability to change the thread pool
|
|
type for any thread pool has been removed. It is still possible to adjust
|
|
relevant thread pool parameters for each of the thread pools (e.g., depending
|
|
on the thread pool type, `keep_alive`, `queue_size`, etc.).
|
|
|
|
|
|
==== Analysis settings
|
|
|
|
The `index.analysis.analyzer.default_index` analyzer is not supported anymore.
|
|
If you wish to change the analyzer to use for indexing, change the
|
|
`index.analysis.analyzer.default` analyzer instead.
|
|
|
|
==== Ping timeout settings
|
|
|
|
Previously, there were three settings for the ping timeout:
|
|
`discovery.zen.initial_ping_timeout`, `discovery.zen.ping.timeout` and
|
|
`discovery.zen.ping_timeout`. The former two have been removed and the only
|
|
setting key for the ping timeout is now `discovery.zen.ping_timeout`. The
|
|
default value for ping timeouts remains at three seconds.
|
|
|
|
==== Recovery settings
|
|
|
|
Recovery settings deprecated in 1.x have been removed:
|
|
|
|
* `index.shard.recovery.translog_size` is superseded by `indices.recovery.translog_size`
|
|
* `index.shard.recovery.translog_ops` is superseded by `indices.recovery.translog_ops`
|
|
* `index.shard.recovery.file_chunk_size` is superseded by `indices.recovery.file_chunk_size`
|
|
* `index.shard.recovery.concurrent_streams` is superseded by `indices.recovery.concurrent_streams`
|
|
* `index.shard.recovery.concurrent_small_file_streams` is superseded by `indices.recovery.concurrent_small_file_streams`
|
|
* `indices.recovery.max_size_per_sec` is superseded by `indices.recovery.max_bytes_per_sec`
|
|
|
|
If you are using any of these settings please take the time to review their
|
|
purpose. All of the settings above are considered _expert settings_ and should
|
|
only be used if absolutely necessary. If you have set any of the above setting
|
|
as persistent cluster settings please use the settings update API and set
|
|
their superseded keys accordingly.
|
|
|
|
The following settings have been removed without replacement
|
|
|
|
* `indices.recovery.concurrent_small_file_streams` - recoveries are now single threaded. The number of concurrent outgoing recoveries are throttled via allocation deciders
|
|
* `indices.recovery.concurrent_file_streams` - recoveries are now single threaded. The number of concurrent outgoing recoveries are throttled via allocation deciders
|
|
|
|
==== Translog settings
|
|
|
|
The `index.translog.flush_threshold_ops` setting is not supported anymore. In
|
|
order to control flushes based on the transaction log growth use
|
|
`index.translog.flush_threshold_size` instead.
|
|
|
|
Changing the translog type with `index.translog.fs.type` is not supported
|
|
anymore, the `buffered` implementation is now the only available option and
|
|
uses a fixed `8kb` buffer.
|
|
|
|
The translog by default is fsynced after every `index`, `create`, `update`,
|
|
`delete`, or `bulk` request. The ability to fsync on every operation is not
|
|
necessary anymore. In fact, it can be a performance bottleneck and it's trappy
|
|
since it enabled by a special value set on `index.translog.sync_interval`.
|
|
Now, `index.translog.sync_interval` doesn't accept a value less than `100ms`
|
|
which prevents fsyncing too often if async durability is enabled. The special
|
|
value `0` is no longer supported.
|
|
|
|
==== Request Cache Settings
|
|
|
|
The deprecated settings `index.cache.query.enable` and
|
|
`indices.cache.query.size` have been removed and are replaced with
|
|
`index.requests.cache.enable` and `indices.requests.cache.size` respectively.
|
|
|
|
`indices.requests.cache.clean_interval has been replaced with
|
|
`indices.cache.clean_interval and is no longer supported.
|
|
|
|
==== Field Data Cache Settings
|
|
|
|
The `indices.fielddata.cache.clean_interval` setting has been replaced with
|
|
`indices.cache.clean_interval`.
|
|
|
|
==== Allocation settings
|
|
|
|
The `cluster.routing.allocation.concurrent_recoveries` setting has been
|
|
replaced with `cluster.routing.allocation.node_concurrent_recoveries`.
|
|
|
|
==== Similarity settings
|
|
|
|
The 'default' similarity has been renamed to 'classic'.
|
|
|
|
==== Indexing settings
|
|
|
|
The `indices.memory.min_shard_index_buffer_size` and
|
|
`indices.memory.max_shard_index_buffer_size` have been removed as
|
|
Elasticsearch now allows any one shard to use amount of heap as long as the
|
|
total indexing buffer heap used across all shards is below the node's
|
|
`indices.memory.index_buffer_size` (defaults to 10% of the JVM heap).
|
|
|
|
==== Removed es.max-open-files
|
|
|
|
Setting the system property es.max-open-files to true to get
|
|
Elasticsearch to print the number of maximum open files for the
|
|
Elasticsearch process has been removed. This same information can be
|
|
obtained from the <<cluster-nodes-info>> API, and a warning is logged
|
|
on startup if it is set too low.
|
|
|
|
==== Removed es.netty.gathering
|
|
|
|
Disabling Netty from using NIO gathering could be done via the escape
|
|
hatch of setting the system property "es.netty.gathering" to "false".
|
|
Time has proven enabling gathering by default is a non-issue and this
|
|
non-documented setting has been removed.
|
|
|
|
==== Removed es.useLinkedTransferQueue
|
|
|
|
The system property `es.useLinkedTransferQueue` could be used to
|
|
control the queue implementation used in the cluster service and the
|
|
handling of ping responses during discovery. This was an undocumented
|
|
setting and has been removed.
|
|
|
|
==== Cache concurrency level settings removed
|
|
|
|
Two cache concurrency level settings
|
|
`indices.requests.cache.concurrency_level` and
|
|
`indices.fielddata.cache.concurrency_level` because they no longer apply to
|
|
the cache implementation used for the request cache and the field data cache.
|
|
|
|
==== Using system properties to configure Elasticsearch
|
|
|
|
Elasticsearch can be configured by setting system properties on the
|
|
command line via `-Des.name.of.property=value.of.property`. This will be
|
|
removed in a future version of Elasticsearch. Instead, use
|
|
`-E es.name.of.setting=value.of.setting`. Note that in all cases the
|
|
name of the setting must be prefixed with `es.`.
|
|
|
|
==== Removed using double-dashes to configure Elasticsearch
|
|
|
|
Elasticsearch could previously be configured on the command line by
|
|
setting settings via `--name.of.setting value.of.setting`. This feature
|
|
has been removed. Instead, use
|
|
`-Ees.name.of.setting=value.of.setting`. Note that in all cases the
|
|
name of the setting must be prefixed with `es.`.
|