EOFS for ApsaraDB for Redis instances that run Redis 2.8 - ApsaraDB for Redis

Starting July 31, 2024, ApsaraDB for Redis is scheduled to discontinue full support for instances that run Redis 2.8. At the end of full support (EOFS), we will no longer provide feature updates, security fixes, and technical support for the version. Upgrade your instances to a later version at the earliest opportunity.

Effective from

00:00:00 on July 31, 2024

Impacts

Existing instances that run Redis 2.8 can still be used, but full support for the instances is coming to an end. This end of support covers the following aspects:

Service purchase is not allowed.
Iterative feature upgrade is not allowed.
Renewal is not allowed.
Configuration change and scaling are not allowed.
After-sales service is unavailable.
New patch releases and bug fixes are unavailable.

Suggestions

Upgrade the major version: As Redis 4.0 is also approaching the end of its lifecycle, we recommend that you upgrade instances that run Redis 4.0 to run Redis 5.0. Redis 5.0 is fully backward compatible with the commands from Redis 2.8 and Redis 4.0. In addition, Redis 5.0 has made significant improvements in key areas such as master-replica replication and persistence mechanisms, and introduces more new features.
Upgrading the major version of an instance typically does not result in data loss and usually has minimal impact on the business. However, we recommend that you upgrade your instances during off-peak hours. The upgrade process of an instance entails the following steps:
1. Upgrade the replica node first. During this phase, the master node remains fully operational with support for normal read and write operations.
2. After the replica node is upgraded, perform a master-replica switchover. The master-replica switchover time is determined based on your specifications at the time of initiating the upgrade. You can choose to perform the switchover immediately or schedule the switchover to occur during the specified maintenance window. During the switchover, the instance experiences transient connections that last for a few seconds and remains read-only for up to 60 seconds until all data is synchronized. Make sure that your application can automatically reconnect to the instance.
  Note
  After the upgrade is complete, the configurations of the original instance, such as the instance ID, endpoints, data, whitelists, accounts, and account passwords, remain unchanged.
Clone data from an instance that runs Redis 2.8 to an instance that runs Redis 5.0: If you want to validate the upgrade against your current business logic in Redis 5.0, you can clone a new instance first.
Change the configurations of an instance: You can use the configuration change feature to change your instance into an instance that runs Redis 5.0 or an ApsaraDB for Redis Enhanced Edition (Tair) instance.

FAQ

Is it mandatory to upgrade an instance that runs Redis 2.8 to a later major version?

It is not mandatory to upgrade an instance that runs Redis 2.8 to a later major version. However, we recommend that you perform the upgrade.

What commands does later versions of Redis support?

Extensive compatibility regression testing has been performed on the data structures and APIs of later versions of ApsaraDB for Redis. For more information, see Commands supported by ApsaraDB for Redis Community Edition.

How do I test the compatibility before an upgrade?

You can restore the backup data of an instance that runs Redis 2.8 to a new instance that runs Redis 5.0. For more information, see Clone data from an instance that runs Redis 2.8 to an instance that runs Redis 5.0.

During the configuration process, select Redis 5.0 as the major version for the new instance, and select the pay-as-you-go billing method to conduct testing and validation at a lower cost. After you complete the necessary testing and validation, you can release the instance to conserve resources.

ApsaraDB for Redis:[Notice] EOFS scheduled for ApsaraDB for Redis instances that run Redis 2.8