Engine versions and upgrading
MAJOR versions are for API incompatible changes and MINOR versions are for new functionality added in a backwards-compatible way. PATCH versions are for backwards-compatible bug fixes and non-functional changes.
Version management for ElastiCache Serverless
ElastiCache Serverless automatically applies the latest MINOR and PATCH software version to your cache, without any impact or downtime to your application. No action is required on your end.
When a new MAJOR version is available, ElastiCache Serverless will send you a notification in the console and an event in EventBridge. You can choose to upgrade your cache to the latest major version by modifying your cache using the Console, CLI, or API and selecting the latest engine version.
Version management for self-designed ElastiCache clusters
When working with self-designed ElastiCache clusters, you can control when the software powering your cache cluster is upgraded to new versions that are supported by ElastiCache . You can control when to upgrade your cache to the latest available MAJOR, MINOR, and PATCH versions. You initiate engine version upgrades to your cluster or replication group by modifying it and specifying a new engine version.
You can control if and when the protocol-compliant software powering your cache cluster is upgraded to new versions that are supported by ElastiCache. 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.
Because version upgrades might involve some compatibility risk, they don't occur automatically. You must initiate them.
To upgrade to a newer Memcached version, modify your cache cluster specifying the new engine version you want to use. Upgrading to a newer Memcached version is a destructive process – you lose your data and start with a cold cache. For more information, see Modifying clusters.
You should be aware of the following requirements when upgrading from an older version of
Memcached to Memcached version 1.4.33 or newer. CreateCacheCluster and
ModifyCacheCluster fails under the following conditions:
-
If
slab_chunk_max > max_item_size. -
If
max_item_size modulo slab_chunk_max != 0. -
If
max_item_size > ((max_cache_memory - memcached_connections_overhead) / 4).The value
(max_cache_memory - memcached_connections_overhead)is the node's memory useable for data. For more information, see Memcached connection overhead.
Upgrade considerations when working with self-designed clusters
Note
The following considerations only apply when upgrading self-designed clusters. They do not apply to ElastiCache Serverless.
When upgrading a self-designed cluster, consider the follwing
Engine version management is designed so that you can have as much control as possible over how patching occurs. However, ElastiCache reserves the right to patch your cluster on your behalf in the unlikely event of a critical security vulnerability in the system or cache software.
-
Because the Memcached engine does not support persistence, Memcached engine version upgrades are always a disruptive process that clears all cache data in the cluster.
How to upgrade engine versions
To start version upgrades to your cluster, you modify it and specify a newer engine version. You can do this by using the ElastiCache console, the Amazon CLI, or the ElastiCache API:
-
To use the Amazon Web Services Management Console, see – Modifying clusters through the console.
-
To use the Amazon CLI, see Modifying clusters with the CLI.
-
To use the ElastiCache API, see Modifying clusters through the API.