NOTE: You are looking at documentation for an older release. For the latest information, see the current release documentation.
This section discusses the changes that you need to be aware of when migrating your application to Elasticsearch 6.3.
Suggest stats metrics deprecatededit
The suggest stats were previously folded into the search on the indices stats
API. As such, the
suggest metric on the indices stats API has been a synonym
search metric. In 6.3.0, the
suggest metric is deprecated in favor
suggest index metric on the
indices metric on the nodes stats
API has provided a response containing only an empty object since 5.0.0. In
6.3.0 this metric has been deprecated.
Starting with version 6.3, all of the X-Pack features ship with the default distribution of Elasticsearch. You no longer need to install X-Pack separately.
Deprecation of the
x-pack configuration directoryedit
In 6.2 and earlier releases, the
security configuration files, such as the
files, were located in an
x-pack directory within the
Starting in 6.3, the security configuration files are located directly in the config directory.
If you upgraded to 6.3, your old security configuration files still
exist in an
x-pack folder. That path is deprecated, however, and you should
move your files out of that folder. There is a known problem where the files in
the old path are disregarded in favor of the files in the new path:
#33688. For more information, see
Failures due to relocation of the configuration files.
Settings such as
files.role_mapping now default to
ES_PATH_CONF/role_mapping.yml. If you do not want to use the default locations,
you must update the settings appropriately. See Security settings.
GCS Repository pluginedit
The repository settings
have been deprecated and must now be specified in the client settings instead.
Ingest Geoip Pluginedit
In earlier versions, database files have been stored as gzip compressed files
with the extension
.gz to save disk space. As a consequence, database files
had to be loaded in memory. Now the default database files that are stored
.mmdb files which allows to memory-map them and save heap
memory. Any custom database files must also be stored uncompressed. Consequently,
database_file property in any ingest pipelines that use the Geoip Processor
must refer to the uncompressed database files as well.
Using the plugin installer without a TTYedit
The Elasticsearch plugin installer (
elasticsearch-plugin install) would
previously silently accept additional security permissions required by a plugin
if standard input was closed or there was no TTY attached (e.g.,
<container ID> elasticsearch-plugin install). This silent accepting of
additional security permissions has been removed. Now, a user must deliberately
accept these permissions either by keeping standard input open and attaching a
TTY (i.e., using interactive mode to accept the permissions), or by passing the
Implementing custom realms with SPI instead of XPackExtensionedit
XPackExtension extension mechanism has been removed and replaced
with an SPI based extension mechanism that is installed and built as an
elasticsearch plugin. For more information about using SPI loaded security
extensions in custom realms, see Integrating with other authentication systems.
Concurrency level of analyze requestsedit
Previously, analyze requests would run on the same thread pool as indexing
index thread pool has been deprecated as it is no longer needed
since indexing requests are internally converted to bulk requests and run on the
bulk thread pool. This leaves analyze requests without a home so we added a
small thread pool called the
analyze thread pool. This thread pool defaults to
having one thread and a queue depth of sixteen requests. This means that
previously analyze requests had a level of concurrency equal to the size of the
index thread pool and now they have a level of concurrency of one. For most
users we think this is fine as analyze requests are useful for debugging and so
probably do not see high concurrency. If you are impacted by this you can
increase the size of the thread pool by using the
Renaming the bulk thread pooledit
bulk thread pool has been renamed to the
write thread pool. This change
was made to reflect the fact that this thread pool is used to execute all write
operations: single-document index/delete/update requests, as well as bulk
requests. The settings
are still supported as fallback settings although you should transition to
thread_pool.write.queue_size, respectively. The
fallback settings will be removed in 7.0.0. Additionally, this means that some
APIs (e.g., the node stats API) will now display the name of this thread pool as
write. If this change impacts you (e.g., for monitoring that you have in
place) you can start Elasticsearch with the JVM option
-Des.thread_pool.write.use_bulk_as_display_name=true to have Elasticsearch
continue to display the name of this thread pool as
bulk. Elasticsearch will
stop observing this system property in 7.0.0.
By default when you install X-Pack, monitoring is enabled but data collection
is disabled. To enable data collection, use the new
xpack.monitoring.collection.enabled setting. You can update this setting by
using the Cluster Update Settings API. For more
information, see Monitoring settings.