Elasticsearch:Instance architecture upgrade

• Version: The upgrade supports same-version migration across architectures. For example, a v2 architecture instance running version 5.5 remains on version 5.5 after being upgraded to the v3 architecture.

• Upgrade method: Instances with a v1/v2 architecture can be upgraded to the v3 architecture manually or automatically.

• Instance type limitations: The upgrade is not supported for v1/v2 architecture instances with the following specifications: 1-core 2 GB, 2-core 2 GB, 4-core 4 GB, 8-core 8 GB, 12-core 12 GB, or 16-core 16 GB.

• Region limitations: Upgrades are supported only within the same region. The source (v1/v2) and target (v3) instances must be in the same region.

• Feature limitations: The upgrade is not supported if the v1/v2 architecture instance has any of the following features enabled:

  • Core features: cross-cluster replication (CCR), , inter-instance network connectivity, high availability (HA), application performance management (APM), or Logstash.

  • Extended features: Elastic scaling (such as auto-scaling) or Nginx reverse proxy.

  • Storage features: OpenStore (Log Enhanced Edition) is enabled or local disks are used.

  • Basic requirements: X-Pack is not enabled.

  • Zone: The primary zone is not on the list of zones supported by the v3 architecture.

• Operation limitations: All instance modification operations are prohibited during the upgrade. Make the necessary operational preparations in advance.

• Upgrade process and duration:

  • The upgrade is performed as a blue-green deployment during a scheduled maintenance window. The cluster topology temporarily displays double the number of nodes. No extra fees are incurred.

  • The upgrade duration is proportional to the data volume and typically lasts several hours. The old nodes are taken offline during your specified maintenance window. This process causes a brief service interruption of 1 to 2 seconds.

Step 1: Create upgrade task

1. Go to the online upgrade page.

   1. Log on to the Alibaba Cloud Elasticsearch console.

   2. In the navigation pane on the left, choose Elastic Stack Cloud Native PaaS > Online Migration Tool.

2. Click Create to create an upgrade task and configure its parameters.

   Parameter	Description
   Type	Select Architecture Upgrade for Alibaba Cloud Elasticsearch Cluster to upgrade a v1/v2 architecture instance to the v3 architecture and complete data migration.
   Cluster	Select the v1/v2 architecture instance that you want to upgrade in the target region.

3. Click OK to create the task.

Step 2: Configure and run upgrade task

In this step, follow the on-screen instructions to configure the upgrade task and complete the data migration.

1. Upgrade check and merge configuration.

   On the Configure Source and Destination Clusters tab, follow these steps to perform a feasibility check for the upgrade task and configure the merge.

   1. Feasibility check: Before you perform the upgrade, the system automatically checks the health and security of the source cluster to ensure that the upgrade is safe and feasible.

      Note

      • If the source cluster is unhealthy or the cluster watermark is too high, we recommend that you do not perform the upgrade.

      • If X-Pack is not enabled for the source cluster, the upgrade is not supported.

      If the feasibility check fails, modify the configurations as prompted.

   2. Configure merge: The system automatically detects the configuration parameters of the source cluster, such as the number of replica shards, sharding policies, and user permissions. Then, it creates a target cluster based on this configuration, ensuring that parameters, resources, and policies are synchronized for a smooth upgrade.

      Note

      This step takes about 20 minutes.

2. Data migration.

   On the Migrate Data tab, follow the steps shown in the following figure to complete the cluster merge, replica migration, master node migration, and primary shard migration in sequence.

   Actions	Description	Description
   Cluster merge	The source and target clusters are merged into a single, larger cluster. After the merge, the total number of nodes in the cluster = number of nodes in the source cluster + number of nodes in the target cluster.	After the cluster merge, Kibana for the target cluster is temporarily disabled. During data migration, you can continue to use the source cluster's Kibana until the service switchover is complete.
   Replica migration	The system migrates index replica shards from the source cluster nodes to the target cluster nodes.	If a failure occurs or services are affected during replica migration, you can roll back the operation. After a rollback, the upgrade task fails, and you must create a new one.
   Master node migration	The system migrates the master node in the merged cluster from the source cluster to the target cluster.	This change takes effect immediately once the migration begins and cannot be rolled back. Proceed with caution. Note For instances of version 7.x and later, the master node is automatically switched to a node in the target cluster. For instances of versions 5.x and 6.x, which do not support automatic switching, the new node is promoted to the master node only after the network isolation is complete and the old node goes offline.
   Primary shard migration	The system migrates the primary shards that store the original data from the source cluster nodes to the target cluster nodes.	After primary shard migration starts, the operation cannot be rolled back. Proceed with caution.

3. Network isolation.

   On the Switch Business tab, follow the on-screen instructions to initiate a network isolation request. This prevents the nodes of the source cluster from joining the target cluster. The source cluster stops providing services, and the target cluster takes over.

4. Upgrade completion.

   After network isolation is successful, the upgrade task is complete. Click Go to Cluster List to view instance details.

Step 3: Validate data

After the architecture upgrade and data migration are complete, access the target v3 instance from the Kibana console. Run queries and write operations to verify that the cluster works as expected. If you encounter any issues, contact Alibaba Cloud Elasticsearch technical support.