Tair (Redis OSS-compatible) continuously optimizes the database (DB) kernel and proxy components to add features, fix known bugs, and improve service stability. You can upgrade the database kernel and proxy components to the latest version with a single click in the console or configure an automatic upgrade policy.
Precautions
When you upgrade the database version, the system first upgrades the replica instance or prepares a new instance. At the specified running time, a primary/secondary failover or instance switch occurs to complete the upgrade. During the instance switch, the instance is in a read-only state for up to 60 seconds while data is fully synchronized. A transient connection interruption that lasts for a few seconds also occurs. Ensure that your application has a reconnection mechanism.
Upgrading the proxy version:
If the instance is a cloud-native edition, the proxy nodes in the instance restart one by one. All connections are disconnected. Ensure that your application has a reconnection mechanism.
If the instance is a classic edition, the instance uses a hot upgrade. The new proxy node recovers connections based on the client connection information from the old proxy node. This process avoids connection interruptions, but millisecond-level latency jitter may occur. However, commands such as BLOCK, Transactions, and Pub/Sub are interrupted. Ensure that these commands in your application have a reconnection mechanism. If the client connects to the instance using a direct connection address, no commands are affected.
Newer minor versions may be available only in some regions during a phased release. The system automatically detects the minor version of the instance. If the Minor Version Upgrade and Upgrade Proxy buttons in the console are unavailable, the instance is already on the latest version.
Minor versions of the instance kernel are forward-compatible unless specified otherwise. You do not need to worry about compatibility issues from upgrades. For more information, see Tair Minor Version Release Notes, Redis Open-Source Edition Minor Version Release Notes, and Proxy Minor Version Release Notes.
A minor version upgrade does not change the instance's connection address, data, whitelist settings, or created account passwords. However, note the following:
Upgrade during off-peak hours.
Ensure that your application has a reconnection mechanism.
Update levels
LOW: regular updates. LOW-level updates include routine feature updates, such as adding a feature.
MEDIUM: recommended updates. MEDIUM-level updates include optimization of features and modules. LOW-level updates are also included in MEDIUM-level updates.
HIGH: major updates. HIGH-level updates include 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.
Configure automatic upgrades
You can use the Version Management Center to view information about each instance, such as its version status and whether it is the latest version. You can also configure automatic upgrade policies or upgrade instance versions to manage all instance versions from a central location.
Log on to the console and go to the Instances page. In the top navigation bar, select the region in which the instance that you want to manage resides.
In the navigation pane on the left, click Version Management Center.
In the upper-left corner of the page, select the destination region.
On the Version Management Center page, view information for all instances in the current region, such as the Current minor version and whether it is the Latest minor version.
Click Configure to the right of the instance, turn on the Automatic upgrade switch, and configure the automatic upgrade.
After you enable this feature, the system periodically checks for new versions. If a new version is found, the system automatically upgrades the instance within the Update Period in the next 60 days. In special cases, the upgrade may be postponed. For example, if too many O&M events have recently occurred for the same account, the upgrade is rescheduled.
The Update Period is the same as the instance's Maintenance Window. Modifying one synchronizes the change to the other.
NoteYou can select multiple instances to perform Update or Configure operations in a batch.
You can query the upgrade records for instance versions in .
Manual upgrade
Log on to the console and go to the Instances page. In the top navigation bar, select the region in which the instance that you want to manage resides. Then, find the instance and click the instance ID.
In the Configuration Information section, move the pointer over the information icon next to Version or Proxy Version to view the release notes for the version.
After you review the release notes, click or .
NoteIf the Minor Version Upgrade or Upgrade Proxy button is unavailable, the instance is already on the latest version and does not require an upgrade.
In the panel that appears on the right, select a running time for the upgrade.
Click OK.
FAQ
Q: How do I confirm whether a Tair instance is on the latest minor version?
A: If the Minor Version Upgrade or Upgrade Proxy button is grayed out and unavailable, the current version is the latest and does not require an upgrade.
If a panel appears after you click the button, the minor version is not the latest. You can follow the instructions in this topic to complete the upgrade.
Q: Can I upgrade to a specific minor version?
A: No, you cannot. An instance is upgraded to the latest minor version by default. Because minor versions are forward-compatible, you do not need to worry about compatibility issues.
Q: I selected Execute within maintainable time as the running time. Why did the instance status change to "Upgrading Minor Version"?
A: The system is performing preparatory tasks for the upgrade, such as requesting resources and synchronizing data. It does not perform an instance switch or a primary/secondary failover, and your service is not affected. The instance enters a read-only state for up to 60 seconds and a transient connection interruption occurs only during the instance switch or primary/secondary failover.
Q: I changed the instance's Update Policy to Automatic Update . Why has it not been upgraded yet?
A: The upgrade does not start immediately. The system periodically checks for new versions. If a new version is found, the system automatically upgrades the instance within the upgradable period in the next 60 days. In special cases, the upgrade may be postponed. For example, if too many O&M events have recently occurred for the same account, the upgrade is rescheduled. You can query the upgrade plan in the Event Center or perform a manual upgrade immediately.
Q: I chose a manual upgrade. Why do I still receive event notifications for minor version upgrades?
A: A manual upgrade only disables the automatic minor version upgrade service. However, the instance still generates minor version upgrade events in cases such as when the version has high-risk threats or is too old and no longer maintained. If you receive a minor version upgrade event notification, you can adjust the upgrade time (recommended) or cancel the upgrade in the Event Center as needed.
Q: Why do different data shard nodes in a cluster instance have different minor versions?
A: For a classic edition cluster architecture, data shard nodes are deployed with the latest minor version by default during reconstruction or a primary/secondary failover. This can cause different data shard nodes to have inconsistent minor versions, but it does not cause compatibility issues. The console or API displays the lowest version in the cluster. When you perform a minor version upgrade or an upgrade/downgrade on the instance, the minor versions of all data shard nodes are made consistent.
NoteThe minor versions of a cloud-native edition cluster instance are always consistent.
Related API operations
API | Description |
Queries the major and minor version information of an instance. You can also query the release notes for the minor version. | |
Upgrades the minor version of an instance. |