Alibaba Cloud continuously optimizes the kernel of ApsaraDB for Redis to provide more
features or fix known issues and enhance service stability. You can update the kernel
version (minor version) of an ApsaraDB for Redis instance with a few clicks in the
ApsaraDB for Redis console.
Apply for resources that are required to create an instance of a new major version.
These resources include proxy node resources.
Synchronize the full data and incremental data from the original instance to the new
instance.
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.
Check that the upgrade is complete. Then, release the original instance and change
the state of the new instance to Running.
Upgrade the original replica node. In this step, you must stop the original replica
node and create a replica node of a new major version.
Synchronize data from the original master node to the new replica node.
Switch your workloads over from the original master node to the new replica node.
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 VIPs
from the original master node and associates the VIPs to 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.
Upgrade the new replica node (original master node). ApsaraDB for Redis repeats Step
1 and Step 2 to perform the upgrade and synchronize data.
Check that the upgrade is complete. If the instance is in the Running state, the upgrade is successful.
Proxy nodes support hot updates. A proxy node of a new version can restore a connection
based on the client connection information of the proxy node of the earlier version.
This ensures uninterrupted connections. However, a millisecond-level latency jitter
may occur during the update.
Impacts
Object
Impact
Instance minor version
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 reconnect to the original instance.
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, 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 the optimized
Bloom filters. For more information about performance-enhanced instances, see Performance-enhanced instances.
Proxy nodes support hot upgrades. Proxy nodes of the new version can restore a connection
based on the client connection information of proxy nodes of the earlier version.
This ensures that upgrades do not interrupt services. However, a millisecond-level
latency jitter may occur during the upgrades.
The hot upgrades are valid only for normal connections. The execution of the block,
transaction, Pub, and Sub commands is interrupted during hot upgrades. Make sure that
these commands support the reconnection mechanism.
If a Redis client uses a private endpoint to connect to the ApsaraDB for Redis instance,
no commands are affected by a proxy upgrade.
Grayscale releases of later instance minor versions may be implemented only in specific
regions. The system checks the minor version of your instance. If your instance is
of the latest minor version, the Minor Version Upgrade or Upgrade Proxy button in the ApsaraDB for Redis console cannot be found or clicked.
Procedure
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 the instance ID.
In the Basic information section, move the pointer over the icon on the right of Minor Version Upgrade or Upgrade Proxy to view the minor version of the current instance, the minor version to which you
can update, and the release notes of minor versions.
Figure 1. View release notes of minor versions
The icon changes colors based on the minor version update level. The update level
is displayed in green, yellow, or red to represent the regular, recommended, or critical
update.
Update level
Color
Description
LOW
Green
Regular update. This level includes routine feature updates, such as adding a feature.
MEDIUM
Yellow
Recommended update. This level includes optimization of features and modules. LOW-level
updates are also included in MEDIUM-level updates.
HIGH
Red
Critical update. This level includes major updates that ensure stability or security,
such as fixing a vulnerability or defect. LOW-level and MEDIUM-level updates are also
included in HIGH-level updates.
After you view the release notes of minor versions, click Minor Version Upgrade or Upgrade Proxy.
In the panel that appears, select the time when you want to perform the update.
Note The instance experiences transient connections for a few seconds and stays in the
read-only state for up to 60 seconds during instance switchovers or master/replica
switchovers. We recommend that you click Update During Maintenance to configure switchovers to be performed during the maintenance window of the instance.
This way, the impacts of switchovers are minimized for the instance. For more information
about how to modify the maintenance window, see Set a maintenance window.
Click OK.
FAQ
Q: Why does an instance change to the Upgrading Minor Version state after I select
Update During Maintenance to update the minor version?
A: When the system prepares for updates, such as applying for resources and synchronizing
data, instances or master and replica nodes are not switched over. This way, instances
that provide services 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.
