Engine versions and upgrading - Amazon MemoryDB for Redis

Engine versions and upgrading

This section covers the supported Redis engine versions and how to upgrade.

Supported Redis versions

Redis version 6.2 (enhanced)

MemoryDB introduces the next version of the Redis engine, which includes Authenticating users with Access Control Lists (ACLs), automatic version upgrade support, client-side caching and significant operational improvements.

With Redis 6, MemoryDB will offer a single version for each Redis OSS minor release, rather than offering multiple patch versions. This is designed to minimize confusion and ambiguity on having to choose from multiple minor versions. MemoryDB will also automatically manage the minor and patch version of your running clusters, ensuring improved performance and enhanced security. This will be handled through standard customer-notification channels via a service update campaign. For more information, see Service updates in MemoryDB for Redis.

If you do not specify the engine version during creation, MemoryDB will automatically select the preferred Redis version for you. On the other hand, if you specify the engine version by using 6.2, MemoryDB will automatically invoke the preferred patch version of Redis 6.2 that is available.

For example, when you create a cluster, you set the --engine-version parameter to 6.2. The cluster will be launched with the current available preferred patch version at the creation time. Any request with a full engine version value will be rejected, an exception will be thrown and the process will fail.

When calling the DescribeEngineVersions API, the EngineVersion parameter value will be set to 6.2 and the actual full engine version will be returned in the EnginePatchVersion field.

For more information on the Redis 6.2 release, see Redis 6.2 Release Notes at Redis on GitHub.

Upgrading engine versions

MemoryDB by default automatically manages the patch version of your running clusters through service updates. You can additionally opt out from auto minor version upgrade if you set the AutoMinorVersionUpgrade property of your clusters to false. However, you can not opt out from auto patch version upgrade.

You can control if and when the protocol-compliant software powering your cluster is upgraded to new versions that are supported by MemoryDB before auto upgrade starts. This level of control enables you to maintain compatibility with specific versions, test new versions with your application before deploying in production, and perform version upgrades on your own terms and timelines.

You can initiate engine version upgrades to your cluster in the following ways:

Note the following:

  • You can upgrade to a newer engine version, but you can't downgrade to an older engine version. If you want to use an older engine version, you must delete the existing cluster and create it anew with the older engine version.

  • Engine version management is designed so that you can have as much control as possible over how patching occurs. However, MemoryDB reserves the right to patch your cluster on your behalf in the unlikely event of a critical security vulnerability in the system or software.

  • MemoryDB will offer a single version for each Redis OSS minor release, rather than offering multiple patch versions. This is designed to minimize confusion and ambiguity on having to choose from multiple versions. MemoryDB will also automatically manage the minor and patch version of your running clusters, ensuring improved performance and enhanced security. This will be handled through standard customer-notification channels via a service update campaign. For more information, see Service updates in MemoryDB for Redis.

  • You can upgrade your cluster version with minimal downtime. The cluster is available for reads during the entire upgrade and is available for writes for most of the upgrade duration, except during the failover operation which lasts a few seconds.

  • We recommend that you perform engine upgrades during periods of low incoming write traffic.

    Clusters with multiple shards are processed and patched as follows:

    • Only one upgrade operation is performed per shard at any time.

    • In each shard, all replicas are processed before the primary is processed. If there are fewer replicas in a shard, the primary in that shard might be processed before the replicas in other shards are finished processing.

    • Across all the shards, primary nodes are processed in series. Only one primary node is upgraded at a time.

How to upgrade engine versions

You initiate version upgrades to your cluster by modifying it using the MemoryDB console, the AWS CLI, or the MemoryDB API and specifying a newer engine version. For more information, see the following topics.

Resolving blocked Redis engine upgrades

As shown in the following table, your Redis engine upgrade operation is blocked if you have a pending scale up operation.

Pending operations Blocked operations
Scale up Immediate engine upgrade
Engine upgrade Immediate scale up
Scale up and engine upgrade Immediate scale up
Immediate engine upgrade