It is time to say goodbye: This version of Elastic Cloud Enterprise has reached end-of-life (EOL) and is no longer supported.

The documentation for this version is no longer being maintained. If you are running this version, we strongly advise you to upgrade. For the latest information, see the current release documentation.

« Add User Settings Advanced Cluster Configuration »
Elastic Docs ›Elastic Cloud Enterprise Reference [1.0] ›Administering Clusters ›Change Your Cluster Configuration

Upgrade a Cluster

edit

Upgrade a Cluster

edit

When changing the version of an existing cluster, either a major or a minor upgrade is performed. The difference is that a minor upgrade takes you from 2.2 to 2.3, for example, and requires no downtime as a rolling upgrade is performed. A major upgrade takes you from from 2.3 to 5.0, for example, and requires a full cluster restart as part of the upgrade process.

Major version upgrades sometimes require other changes due to breaking changes or discontinued features. For example, some special considerations apply when upgrading to Elasticsearch 5.0. Our recommended approach for major version upgrades is to create a new cluster with the latest major version you want to upgrade to, reindex everything and make sure index requests are temporarily sent to both clusters. With the new cluster ready, tested, and working, you can then remove the old cluster.

To upgrade a cluster in Elastic Cloud Enterprise:

  1. Log into the Cloud UI.
  2. Click on a cluster name from the Clusters panel and click Edit icon.

  3. Select one of the available software versions. Let the user interface guide you through the steps for upgrading a cluster. When you save your changes, your cluster configuration is updated to the new version.

    You cannot downgrade after upgrading, so plan ahead to make sure that your applications still work after upgrading. For more information on changes that might affect your applications, see Breaking changes.

Upgrading to Elasticsearch 5.0

edit

Elasticsearch 5.0 provides major new features and improved usability, but there are a few things you need to keep in mind when upgrading to our latest and greatest software in Elastic Cloud.

Limitations and Known Problems
edit

Due to a known problem with the transport protocol on Elastic Cloud, the Java transport client is not yet supported on version 5.0. A fix is being worked on.

Breaking Changes in Elasticsearch 5.0
edit

A number of Elasticsearch queries were deprecated in version 2.0 or later and removed in version 5.0. Applications running deprecated queries might break after upgrading to 5.0.

Starting in Elasticsearch 2.3, a deprecation log became available that can help you determine if your applications are affected. Check this deprecation log before upgrading. If you are using deprecated queries, you will need to update your applications.

A number of other items were changed or removed in Elasticsearch 5.0 and later as well. For more information, see Breaking changes in 5.6.

Migrating Shield Configurations
edit

In Elasticsearch 5.0, the security features required to keep your Elastic Cloud clusters safe became part of X-Pack. With the move to X-Pack, the biggest changes to security features for the Elastic Stack include the names of the security configuration options, TLS/SSL configuration, and how roles are defined. A few privileges have also been removed.

When you upgrade an Elasticsearch cluster on Elastic Cloud to version 5.0, the upgrade process to the new X-Pack security features is handled for you. As part of the upgrade process, all users, roles, and user-role mappings that exist in your Shield configuration are upgraded to use the new X-Pack security features. In addition, two users are always created on version 5.0 clusters, the elastic superuser and the anonymous user.

If your cluster never had an active Shield configuration or if you are not provided the password during the upgrade process, you might need to reset the password for the elastic user after upgrading to Elasticsearch 5.0. Users and applications will need to authenticate to be able to connect to your cluster.

After the upgrade is complete, you use the Kibana Management app for X-Pack to work with users and roles, which replaces the Shield Editor in previous releases:

User and role management in Kibana

To learn more about working with X-Pack security features in Elastic Cloud Enterprise, see Manage Users and Roles in X-Pack. For more background information about X-Pack for the Elastic Stack, see Securing Elasticsearch and Kibana.

Indices Originally Created in Older Versions of Elasticsearch
edit

Indices created in Elasticsearch before version 2.0 are not compatible with version 5.0, even if you upgraded your cluster to version 2.0 or later at some point. In order to upgrade to Elasticsearch 5.0 with these indices, you must perform some additional steps.

For Elastic Cloud Enterprise, this section applies to you only if you restored snapshots with indices created before version 2.0. Note that snapshots cannot be restored in Elasticsearch 5.0 directly, if they contain indices created in an Elasticsearch version before 2.0. To work around this restriction, you either need to discard these snapshots or you need to open them on a cluster running Elasticsearch 2.3 before reindexing and creating new snapshots.

If you upgrade to Elasticsearch 5.0 with indices that are not supported, your Elasticsearch cluster will not start. Please make sure you follow the steps in this section first.

The following steps apply to you if your current cluster was originally created in a version of Elasticsearch before 2.0 or if you are not sure what version your cluster originally used:

  1. Check if you can upgrade to Elasticsearch 5.0 directly.

    For all versions of Elasticsearch: You can find out what version of Elasticsearch an index was created with by querying the index settings and looking at the value of settings.index.version.created. The first number in the value indicates the major version of Elasticsearch and any value that is below 2000000 is not readable in Elasticsearch 5.0, even if settings.index.version.upgraded shows a value that is greater than or equal to 2000000.

    For example:

    - newdata: {
    aliases: { },
  + mappings: {…},
  - settings: {
      - index: {
          refresh_interval: "-1",
          number_of_shards: "5",
        - translog: {
            durability: "async"
        },
        creation_date: "1460043613621",
        number_of_replicas: "1",
        uuid: "n6kYaMYGT0OJx8McwGAzPw",
      - version: {
          created: "2030099"
          upgraded: "5000002"
        }
    }
  },
  warmers: { }
},

    Here is how you read the example:

    • If created indicates a value that is greater than or equal to 2000000, you can upgrade to Elastisearch 5.0 directly. In this example, the index was created with version 2.3.0 (created: "2030099"). You can skip the rest of the steps in this section and proceed to upgrade your cluster.

    • If created indicates a value that is smaller than 2000000, you cannot upgrade to Elastisearch 5.0 directly. Follow the remaining steps in this section first before upgrading to Elastisearch 5.0.

      Examples of created values that prevent you from upgrading to to Elastisearch 5.0 directly:

      1070199
      Indicates an index created with Elasticsearch 1.7.1.
      1060299
      Indicates an index created with Elasticsearch 1.6.2.

    For Elasticsearch 2.0 and later: You can see a human-friendly value for the version that an index was created with by appending ?human=true to your query URL.

    For example, for the index named test, the URL http://127.0.0.1:9200/test?human=true returns a human-friendly version with the created_string (some output has been omitted for clarity):

    ...
created_string: "2.3.2",
created: "2030299"
...
  2. If you cannot upgrade to Elasticsearch 5.0 directly, you can upgrade your indices on a cluster running Elasticsearch 2.3.x yourself with the Reindex API. For more information, see Reindex to upgrade.
« Add User Settings Advanced Cluster Configuration »