Engine versions and upgrading
This section covers the supported Redis engine versions and how to upgrade.
Supported Redis versions
MemoryDB for 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.
Redis engine version 6.2.6 also introduces support for native JavaScript Object Notation (JSON) format, a simple, schemaless way to encode complex datasets
inside Redis clusters. With JSON support, you can leverage the performance and Redis APIs for applications that operate over JSON.
For more information, see Getting started with JSON.
Also included is JSON-related metric JsonBasedCmds that is incorporated into CloudWatch to monitor the usage of this datatype. For more information,
see Metrics for MemoryDB.
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
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:
By updating it and specifying a new engine version. For more information, see Modifying a MemoryDB cluster.
Applying the service update for the corresponding engine version. For more information, see Service updates in MemoryDB for Redis.
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 |
