WARNING: Version 6.0 of the Elastic Stack has passed its EOL date.
This documentation is no longer being maintained and may be removed. If you are running this version, we strongly advise you to upgrade. For the latest information, see the current release documentation.
When upgrading to a new version of Elasticsearch, you need to upgrade each of the products in your Elastic Stack. Beats and Logstash 5.6 are compatible with Elasticsearch 6.0 to give you flexibility in scheduling the upgrade.
We recommend upgrading to the most recent 5.6 before upgrading to 6.0.1. X-Pack 5.6 provides a free Upgrade Assistant that identifies issues you need to address before upgrading and simplifies migrating indices that need to be reindexed before you upgrade. The Upgrade Assistant is enabled with both Trial and Basic licenses. You can install X-Pack solely for the purpose of upgrading. There’s no obligation to continue using X-Pack once your upgrade is complete.
Rolling upgrades are supported when upgrading from Elasticsearch 5.6 to 6.0.1, a full cluster restart is not always required. Upgrading from any other version than 5.6 requires a full cluster restart.
2.x indices are not compatible with 6.0.1. You must remove or reindex them on 5.x before upgrading to 6.0.1. The internal Kibana and X-Pack indices and the default Beats and Logstash mapping templates also need to be updated to work with 6.0.1.
Preparing to upgradeedit
Before upgrading the Elastic Stack to 6.0.1:
- Back up your data. You cannot roll back to an earlier version unless you have a backup of your data. For information about creating snapshots, see Snapshot and Restore.
Check the Elasticsearch deprecation log to see if
you’re using any deprecated features and update your code accordingly.
By default, deprecation log messages are enabled at the
Review the breaking changes for each product you use and make the necessary changes so your code is compatible with 6.0.1:
- If you’re upgrading from 2.x, make sure you check the breaking changes from 2.x to 5.x, as well as from 5.x to 6.x!
- If you are using machine learning datafeeds that contain discontinued search or query domain specific language (DSL), the upgrade will fail. In 5.6.5 and later, the Upgrade Assistant provides information about which datafeeds need to be updated.
- We recommend upgrading to 5.6 and using the Upgrade Assistant's Reindex Helper to reindex 2.x indices. Alternatively, you can manually reindex or delete all 2.x indices.
If Kibana and X-Pack are part of your stack, upgrade the internal Kibana
and X-Pack indices. We recommend using the X-Pack 5.6 Reindex Helper to
upgrade the internal indices. If you’re performing a full cluster restart upgrade
from an earlier version, you can also use the
_xpack/migration/upgradeAPI directly to upgrade the internal indices after you install Elasticsearch 6.0.1.
If you use X-Pack to secure your cluster:
Make sure TLS is enabled to encrypt communications between nodes. TLS must be enabled to upgrade to 6.0.1. For more information, see Encrypting Communications.
Enabling TLS requires a full cluster restart. Nodes that have TLS enabled cannot communicate with nodes that do not have TLS enabled. You must restart all nodes to maintain communication across the cluster.
Make sure real passwords are configured for the built-in
logstash_systemusers. They cannot use the 5.x default password (
changeme). For more information, see Setting Up User Authentication.
- Stop any X-Pack machine learning jobs that are running before starting the upgrade process. See Stopping Machine Learning.
Test upgrades in a dev environment before upgrading your production cluster.
You should upgrade the core Elastic Stack products in the following order:
Logstash 6.0+ and Beats 6.0+ are compatible with all 6.x versions of Elasticsearch. This provides flexibility in when you schedule the upgrades for your Logstash instances and Beats agents. We recommend upgrading Logstash and Beats as soon as possible to take advantage of performance improvements and other enhancements.
If you use Elasticsearch for Hadoop, we recommend disabling ingestion while you upgrade the stack. For more information, see the Elasticsearch for Hadoop reference.
Upgrading from 5.6edit
X-Pack 5.6 provides migration and upgrade APIs for Elasticsearch and a Upgrade Assistant UI for Kibana. These tools are included with the X-Pack trial license and the free Basic license.
To upgrade to 6.0.1 from 5.6:
Upgrade Elasticsearch to the most recent 5.6 and install X-Pack on all nodes in your cluster. If you are upgrading from an earlier 5.x release, you can perform a rolling upgrade. To upgrade from older versions you must perform a full cluster restart.
If your trial license to use X-Pack expires, register for a free Basic license. To apply the license, upload the license file with the
license -d @license.json
If X-Pack IS NOT normally a part of your Elastic Stack, disable Security in
- Upgrade Kibana to the most recent 5.6 and install X-Pack.
If you disabled X-Pack security in
elasticsearch.yml, also disable Security in
Use the Upgrade Assistant in Kibana to view incompatibilities that you need to fix, identify any 2.x indices that need to be migrated or deleted, and upgrade the internal indices to the 6.x index format.
You can also call the Elasticsearch migration APIs directly:
- Runs a series of checks on your cluster, nodes, and indices and returns a list of issues that need to be fixed before you can upgrade to 6.0.1.
- Upgrades the Watcher and Security indices to a single-type format compatible with Elasticsearch 6.x.
- Once you’ve resolved all of the migration issues, perform a rolling upgrade from Elasticsearch 5.6 to 6.0.1.
Upgrading from a pre-5.6 installationedit
It is possible to upgrade directly to 6.x from a pre-5.6 installation, but it requires a full cluster restart and you must manually reindex any 2.x indices you need to carry forward to 6.x.
If you use Kibana or X-Pack, you also need to upgrade the internal Kibana and X-Pack indices. For information about upgrading them after you install Elasticsearch 6.0.1, see Upgrading internal indices.
To manually reindex a 2.x index:
- Create an index with 6.x compatible mappings.
- Use the reindex API to copy documents from the 2.x index into the new index. You can use a script to perform any necessary modifications to the document data and metadata during reindexing.
- Use the _aliases API to add the name of the 2.x index as alias for the new index and delete the 2.x index.
Upgrading internal indices for 6.xedit
The format used for the internal indices used by Kibana and X-Pack has changed in 6.x. Before you can run Kibana and X-Pack in 6.0.1, these indices must be upgraded to the new format.
Starting in 5.6, X-Pack provides an Upgrade Assistant you can use to upgrade the internal indices.
If you are upgrading from a version prior to 5.6, you must upgrade the internal indices after installing Elasticsearch 6.0.1:
If X-Pack Security is enabled, create a
temporary super user in the
filerealm on a single node.
- Start Elasticsearch.
Manually upgrade the
.kibanaindex using the temporary superuser credentials.
- Start Kibana.
Log in to Kibana with the temporary superuser credentials and use the Upgrade
Assistant to migrate the X-Pack indices. (You could also do this manually with
- Delete the temporary superuser from the file realm.
Upgrading on Elastic Cloudedit
A single click in the Elastic Cloud console can upgrade a cluster to a newer version, add more processing capacity, change plugins, and enable or disable high availability, all at the same time. During the upgrade process, Elasticsearch, Kibana, X-Pack and the officially included plugins are upgraded simultaneously.
Although upgrading your Elastic Cloud clusters is easy, you still need to address breaking changes that affect your application. Minor version upgrades, upgrades from 5.6 to 6.x, and all other cluster configuration changes can be performed with no downtime.
To avoid downtime when a full cluster restart is required:
- Provision an additional cluster with the new Elasticsearch version, reindex your data, and send index requests to both clusters temporarily.
- Verify that the new cluster performs as expected, fix any problems, and then permanently swap in the new cluster.
- Delete the old cluster to stop incurring additional costs. You are billed only for the time that the new cluster runs in parallel with your old cluster. Usage is billed on an hourly basis.
To learn more about the upgrade process on Elastic Cloud, see Upgrade versions.
Elastic Cloud only supports upgrades to released versions. Preview releases and master snapshots are not supported.