This topic describes how to upgrade the major version of an ApsaraDB for Redis instance in the ApsaraDB for Redis console to use the features of the new major version. For example, you can upgrade the major version from Redis 2.8 to Redis 4.0.

Workflow

The upgrade workflow varies based on the architecture of the instance. For more information, see the following table.

Architecture Workflow
Cluster
  1. Apply for resources that are required to create an instance of a new major version. These resources include proxy node resources.
  2. Synchronize full data and incremental data from the original instance to the new instance.
  3. Switch your workloads over from the original instance to the new instance. When data is synchronized to completion, the original instance is put into the read-only state and remains in the state for up to 60 seconds until all data is synchronized. After data synchronization is complete, ApsaraDB for Redis disassociates the virtual IP addresses (VIPs) from the original instance and associates the VIPs with the new instance.
    Note If you select Update During Maintenance, ApsaraDB for Redis performs the switchover within the specified maintenance window.
  4. Check that the upgrade is complete. Then, release the original instance and change the state of the new instance to Running.
Read/write splitting
Standard
  1. Upgrade the original replica node. In this step, the system stops the original replica node and creates a replica node of a new major version.
  2. Synchronize data from the original master node to the new replica node.
  3. Switch your workloads over from the original master node to the new replica node. When data is synchronized to completion, the instance is put into the read-only state and remains in the state for up to 60 seconds until all data is synchronized. After data synchronization is complete, ApsaraDB for Redis disassociates the VIPs from the original master node and associates the VIPs with the new replica node. In addition, ApsaraDB for Redis switches your workloads over from the original master node to the new replica node and promotes the new replica node to the new master node. The original master node is demoted to the new replica node.
    Note If you select Update During Maintenance, ApsaraDB for Redis performs the switchover within the specified maintenance window.
  4. Upgrade the new replica node (original master node). ApsaraDB for Redis repeats Step 1 and Step 2 to perform the upgrade and synchronize data.
  5. Check that the upgrade is complete. If the instance is in the Running state, the upgrade is successful.

Impacts

  • When you apply for resources, upgrade the replica node, or synchronize data, your ApsaraDB for Redis service remains available.
  • When you switch your workloads over from the original instance to a new instance or from the master node to the replica node in the original instance, you may experience transient connections that last for a few seconds. The original instance stays in the read-only state for up to 60 seconds until all data is synchronized. We recommend that you upgrade the original instance during off-peak hours and make sure that your application is configured to automatically re-establish a connection.
  • If the original instance runs Redis 4.0, Bloom filter-related API operations such as BF.ADD are no longer supported after you upgrade the major version of the original instance to a version later than Redis 4.0.
    Notice Bloom filter-related API operations on existing instances of ApsaraDB for Redis 4.0 are only for internal use. In addition, new instances that run Redis 4.0 or later no longer support Bloom filter-related API operations. Therefore, if you call Bloom filter-related API operations the new instances, you cannot perform cache analytics and unknown errors may occur. We recommend that you change the original instance into a performance-enhanced instance of the ApsaraDB for Redis Enhanced Edition (Tair) to support optimized Bloom filters. For more information about performance-enhanced instances, see Performance-enhanced instances.

Precautions

  • If a private endpoint is allocated to an ApsaraDB for Redis instance or if a Data Transmission Service (DTS) task is created for the instance, a major version upgrade cannot be performed. You can release the private endpoint or close the DTS task before a major version upgrade. For more information about how to release a private endpoint for an instance, see Release a private endpoint for an ApsaraDB for Redis instance.
  • Major version upgrades are not needed for ApsaraDB for Redis Enhanced Edition (Tair) instances.

Procedure

  1. Log on to the ApsaraDB for Redis console and go to the Instances page. In the top navigation bar, select the region in which the instance is deployed. Then, find the instance and click its ID.
  2. In the Basic information section, click Major Update.
    Figure 1. Upgrade the major version
    Upgrade the major version of an instance
    Note If the Major Update button does not exist, you are using the latest major version.
  3. In the panel that appears, specify the new major version and the time when you want to perform the upgrade.
    Notice When you switch your workloads over from the original instance to a new instance or from the master node to the replica node in the original instance, you may experience transient connections that last for a few seconds. The original instance stays in the read-only state for up to 60 seconds until all data is synchronized. We recommend that you select Update During Maintenance. This way, ApsaraDB for Redis performs the switchover within the specified maintenance window to minimize impacts on your workloads. For more information about how to modify the maintenance window, see Set a maintenance window.
  4. Click OK.

Related API operations

Operation Description
ModifyInstanceMajorVersion Upgrades the major version of an ApsaraDB for Redis instance.

FAQ

  • Q: Why does the state of an instance change to Upgrading Major Version after I select Update During Maintenance to upgrade the major version?
    A: The state of an instance changes to Upgrading Major Version because the system is preparing for the upgrade. During the preparation, the instance service remains available. When the system prepares for upgrades, such as applying for resources and synchronizing data, instances or master and replica nodes are not switched over and services provided are not affected.
    Note The instance experiences transient connections for a few seconds and then remains in the read-only state for up to 60 seconds only during instance switchovers or master/replica switchovers.
  • Q: Why does a major version upgrade of an instance fail?

    A: If your instance is of a phrased-out instance type, its major version cannot be upgraded.In this case, you must change the instance type. You can select a valid instance type for the new instance that has the same specifications as the original instance. Then, you can upgrade the major version of the instance. For more information, see https://www.alibabacloud.com/help/zh/faq-list/164579.htm.