All Products
Search
Document Center

Elasticsearch:Upgrade check

Last Updated:Mar 26, 2026

Before upgrading an Alibaba Cloud Elasticsearch cluster, complete the required manual checks and verify that the cluster status and configuration are compatible with the target version. This topic covers what to check, why each check matters, and how to fix issues before the upgrade proceeds.

All commands in this topic can be run in the Kibana console. For access instructions, see Log on to the Kibana console.

Prerequisites

Before you begin, make sure you have:

  • Access to the Kibana console for your cluster

  • The cluster version you plan to upgrade to confirmed (see Upgrade the version of a cluster for supported upgrade paths)

Required checks

Complete all of the following checks before starting the upgrade.

Check for closed indexes

Run the following command to list all indexes and their statuses:

GET _cat/indices?v
Check for indexes that are in the close state

The output lists each index with its status in the status column. If any index shows a close status, open it before the upgrade:

POST test/_open

Check kernel version availability

If you plan to update the cluster kernel as part of the upgrade, verify that a later kernel version is available on the Basic Information page of your cluster.

A later kernel version is available

You can update the kernel only if a later version is listed.

Check client compatibility

If a client connects to the cluster, verify that its version is compatible with the target cluster version. For version compatibility details, see Compatibility. If the versions are incompatible, upgrade the client before proceeding.

Additional checks for V5.X to V6.X upgrades

If upgrading from V5.X to V6.X, complete the following checks in addition to the required checks above.

Split multi-type indexes

V6.X and later do not support multi-type indexes. If the cluster has multi-type indexes, writing to those indexes still works after the upgrade, but creating new multi-type indexes in V6.X causes errors. Split each multi-type index into single-type indexes before the upgrade.

Disable cross-cluster search

Run the following command to check whether cross-cluster search is enabled:

GET _cluster/settings

If search.remote appears in the result with a non-null value, cross-cluster search is enabled. Disable it before the upgrade:

PUT _cluster/settings
{
  "persistent": {
    "search.remote.*": null
  },
  "transient": {
    "search.remote.*": null
  }
}

After the upgrade, you can re-enable cross-cluster search.

Important

In V5.X, cross-cluster search uses the search.remote parameter. In V6.X, this parameter changes to cluster.remote.

Cluster status check

When you start the upgrade, click Precheck to run an automated check of cluster status and load. The upgrade proceeds only if both pass. Use the following table to verify these conditions manually before clicking Precheck.

Check item Normal state
Cluster status Normal (green)
JVM heap memory usage Less than 75%
Disk usage Less than the value of cluster.routing.allocation.disk.watermark.low
Replica shards All indexes have replica shards configured; for multi-zone clusters, the replica shard count per index must be less than the number of zones
Snapshots A snapshot was created within the last hour
Custom plug-ins No custom plug-ins installed
Elastic Compute Service (ECS) instances Sufficient ECS instances available in the cluster's zone
YML configuration file The YML configuration of the earlier version is compatible with the target version
Note

During the upgrade, the system adds nodes running the target version, migrates data from the original nodes to the new nodes, and then removes the original nodes. Make sure that the zone has enough ECS instances before the upgrade starts.

Configuration compatibility check

When upgrading to V6.X, the system automatically checks for incompatible configurations. To check manually before the upgrade, run:

GET _cluster/settings
GET */_settings?flat_settings=true

The following configurations are incompatible with V6.X:

No. Config level Config category Parameter
1 Cluster Snapshot settings cluster.routing.allocation.snapshot.relocation_enabled
2 Cluster Storage throttling settings indices.store.throttle.type and indices.store.throttle.max_bytes_per_sec
3 Index Similarity settings index.similarity.base
4 Index Shadow replica settings index.shared_filesystem and index.shadow_replicas
5 Index Index storage settings index.store.type
6 Index Storage throttling settings index.store.throttle.type and index.store.throttle.max_bytes_per_sec
7 Index include_in_all mapping setting include_in_all
8 Index Version settings for index creation index.version.created
9 Index template Similarity settings index.similarity.base
10 Index template Shadow replica settings index.shared_filesystem and index.shadow_replicas
11 Index template Index storage settings index.store.type
12 Index template Storage throttling settings index.store.throttle.type and index.store.throttle.max_bytes_per_sec
13 Index template include_in_all mapping setting include_in_all
14 Index template _all mapping setting _all
15 Index template Multiple type settings in mapping
Note

All parameters in the table above are deprecated in V6.0 and later. For details, see Breaking changes in 6.0.

CRITICAL vs WARNING check items:

  • CRITICAL: The cluster cannot be upgraded. Fix the incompatible configuration and recheck.

  • WARNING: The cluster can still be upgraded. The configuration is ignored after the upgrade.

Important

If an index template contains any configuration from this table, the template cannot be used to create indexes after the upgrade.

Notes on specific parameters:

  • include_in_all (item 7): Indexes created before the V5.X to V6.X upgrade that have this parameter configured remain usable after the upgrade. Indexes created after the upgrade do not support this parameter.

  • index.version.created (item 8): This parameter prevents cross-major-version index upgrades. For example, indexes created in V5.X cannot be directly upgraded to V7.X. Before upgrading from V5.X to V7.X, use the Reindex API to migrate data to the V7.X cluster, then delete the V5.X indexes.

  • Item 15 (multiple types in index template mapping): Check whether the mapping configuration in the index template contains multiple type settings.

Fix incompatible configurations

Cluster-level configurations

Disable cluster-level incompatible configurations by setting their values to null.

Snapshot settings:

PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.snapshot.relocation_enabled": null
  },
  "transient": {
    "cluster.routing.allocation.snapshot.relocation_enabled": null
  }
}

Storage throttling settings:

PUT _cluster/settings
{
  "persistent": {
    "indices.store.throttle.type": null,
    "indices.store.throttle.max_bytes_per_sec": null
  },
  "transient": {
    "indices.store.throttle.type": null,
    "indices.store.throttle.max_bytes_per_sec": null
  }
}

Index-level configurations

Disable index-level incompatible configurations by setting their values to null. Replace test_index with your index name.

Config category Command
Similarity settings PUT test_index/_settings with "index.similarity.base.*": null
Shadow replica settings PUT test_index/_settings with "index.shared_filesystem": null, "index.shadow_replicas": null
Index storage settings PUT test_index/_settings with "index.store.type": null
Storage throttling settings PUT test_index/_settings with "index.store.throttle.type": null, "index.store.throttle.max_bytes_per_sec": null

Similarity settings require closing the index first. Closed indexes cannot be read or written to. Reopen the index after making changes.

Close the index:

POST test_index/_close

Update the setting:

PUT test_index/_settings
{
  "index.similarity.base.*": null
}

Open the index:

POST test_index/_open

Shadow replica settings:

PUT test_index/_settings
{
  "index.shared_filesystem": null,
  "index.shadow_replicas": null
}

Index storage settings:

PUT test_index/_settings
{
  "index.store.type": null
}

Storage throttling settings:

PUT test_index/_settings
{
  "settings": {
    "index.store.throttle.type": null,
    "index.store.throttle.max_bytes_per_sec": null
  }
}
Note

Indexes with include_in_all configured remain usable in V6.X. No changes are needed for this parameter.

Index template-level configurations

The following example shows how to fix incompatible configurations in an index template named test_template.

  1. Retrieve the current template:

    GET _template/test_template

    The result shows the incompatible configurations — in this example, index storage settings, _all, and include_in_all:

    {
      "test_template": {
        "order": 0,
        "template": "test_*",
        "settings": {
          "index": {
            "store": {
              "throttle": {
                "max_bytes_per_sec": "100m"
              }
            }
          }
        },
        "mappings": {
          "test_type": {
            "_all": {
              "enabled": true
            },
            "properties": {
              "test_field": {
                "type": "text",
                "include_in_all": true
              }
            }
          }
        },
        "aliases": {}
      }
    }
  2. Remove the incompatible configurations and update the template:

    PUT _template/test_template
    {
       "order": 0,
       "template": "test_*",
       "settings": {
       },
       "mappings": {
         "test_type": {
           "properties": {
             "test_field": {
               "type": "text"
             }
           }
         }
       },
       "aliases": {}
    }

What's next

After completing all checks and fixing any incompatible configurations, proceed with the upgrade. See Upgrade the version of a cluster.