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
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.
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.
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 |
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 | — |
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.
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
}
}
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.
-
Retrieve the current template:
GET _template/test_templateThe result shows the incompatible configurations — in this example, index storage settings,
_all, andinclude_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": {} } } -
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.