Elasticsearch:Cluster architecture upgrade

• Version requirements:

  Source version	Upgrade support	Upgraded version	Special requirements
  6.7, 6.8, 7.10, or 7.16	Supported	Remains the same	For versions 6.7 and 6.8, no indexes can be in the closed state.
  6.3, 7.4, or 7.7	Supported	7.4 or 7.7: Upgrade to 7.10 6.3: Upgrade to 6.8	Indexes must have replicas. Contact technical support to add the instance to a whitelist.
  5.5 or 5.6	Not supported	-	-

• Upgrade method: You can upgrade v1 or v2 instances to the v3 architecture manually or automatically.

• Specification limits: The upgrade is not supported for v1 or v2 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 limit: Upgrades are supported only within the same region. The v1 or v2 instance and the v3 instance must be in the same region.

• Feature limits: The upgrade is not supported if the v1 or v2 instance has the following features enabled:

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

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

  • Storage attributes: OpenStore (Advanced Edition) is enabled or local disks are used.

  • Basic requirements: The X-Pack feature is disabled.

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

• Operation limits: All instance change operations are prohibited during the upgrade. Complete your business preparations in advance.

• Upgrade process and duration:

  • The upgrade is performed using a blue-green deployment during a scheduled period. The cluster topology temporarily shows double the number of nodes. No extra fees are incurred.

  • The upgrade duration is proportional to the data volume and usually takes several hours. The old nodes are taken offline during the operations and maintenance (O&M) window that you set. This process causes a service interruption of about 1 to 2 seconds.

    When upgrading from v1 to v3, the cluster is restarted twice during the network isolation phase, which extends the total duration.

Step 1: Create an 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 to go to the online upgrade page.

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

   Parameter	Description
   Type	Select Architecture Upgrade for Alibaba Cloud Elasticsearch Cluster. This type is used to upgrade a v1 or v2 instance to the v3 architecture and complete data migration.
   Cluster	Select the v1 or v2 instance to upgrade in the destination region.

3. Click OK to create the task.

Step 2: Configure and run the upgrade task

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

1. Perform an upgrade check and configure the merge.

   On the Configure Source and Destination Clusters tab, follow these steps to check the feasibility of the upgrade and configure the merge.

   1. Feasibility check: Before the upgrade, the system automatically performs a health check and a security check on the source cluster to ensure that the upgrade is safe and feasible.

      Note

      • If the source cluster is unhealthy or the cluster usage is too high, do not proceed with the upgrade.

      • If the source cluster does not have X-Pack, the upgrade is not supported.

      If the feasibility check fails, modify the configuration as prompted on the page.

   2. Configure merge: The system automatically detects the configuration parameters of the source cluster, such as the number of replicas, sharding strategy, and user permission settings. The system then creates the destination cluster based on this configuration. This process ensures that the configuration parameters, resource allocation, and sharding strategies of the source and destination clusters are seamlessly synchronized for a smooth upgrade and efficient operation.

      Note

      This step takes about 20 minutes.

2. Migrate data.

   On the Migrate Data tab, follow the steps in the figure to merge the clusters, migrate replicas, migrate the master node, and migrate primary shards.

   Operation	Description	Notes
   Cluster merge	The system merges the source cluster and the destination cluster into a single large cluster. After the merge, the total number of nodes in the cluster = number of nodes in the source cluster + number of nodes in the destination cluster.	After the clusters are merged, Kibana for the destination cluster is temporarily shut down. During data migration, you can still use Kibana for the source cluster until the service switch is complete.
   Replica migration	The system migrates index replica shards from the source cluster nodes to the destination cluster nodes.	If an unexpected failure occurs or your business is affected during replica migration, you can perform a rollback. After the rollback, the current upgrade task cannot continue. You must create a new upgrade task.
   Master node migration	The system migrates the master node in the merged cluster from the source cluster to the destination cluster.	The master node migration starts immediately and cannot be rolled back in any scenario. Proceed with caution. Note For instances of version 7.x and later, the master node is automatically switched to a node in the destination cluster. For instances of version 5.x or 6.x, automatic switchover is not supported. Instead, after network isolation is complete and the old nodes are offline, a new node is promoted to be the master node.
   Primary shard migration	The system migrates the primary shards, which store the raw data, from the source cluster nodes to the destination cluster nodes.	Primary shard migration cannot be rolled back in any scenario after it starts. Proceed with caution.

3. Perform network isolation.

   On the Service Switch tab, follow the instructions on the page to request network isolation. This action prevents nodes from the source cluster from joining the destination cluster. The source cluster stops providing services, and the destination cluster takes over.

4. Complete the upgrade.

   After network isolation is successful, the upgrade task is complete. You can click Go to Instance List to view the instance details.

Step 3: Validate data

After the architecture upgrade and data migration are complete, access the destination v3 instance from the Kibana console. You can run queries or write operations to verify that the cluster works as expected. If you have any questions, contact the Alibaba Cloud Elasticsearch helpdesk for assistance.