Can I upgrade Elasticache Redis Engine Version without downtime?
Asked Answered
F

4

18

I cannot find any information in the AWS documentation that modifying the Redis engine version will or will not cause downtime. It does not explain how the upgrade occurs other than it's performed in the maintenance window.

It is safe to upgrade a production Elasticache Redis instance via the AWS console without loss of data or downtime?

Note: The client library we use is compatible with all versions of Redis so the application should not notice the upgrade.

Flatling answered 29/6, 2015 at 0:37 Comment(0)
A
4

Changing a cache engine version is a disruptive process which clears all cache data in the cluster. **

I don't now the requirements of your particular application. But if you can't lose your data and you need to do a major version upgrade, it would be advisable to migrate to a new cluster rather than upgrading the current setup.

** http://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/VersionManagement.html

Acetone answered 29/6, 2015 at 1:50 Comment(1)
The documentation link you provided now states that Redis engine upgrades will "make a best effort to retain your existing data and requires successful Redis replication".Leanora
C
11

I am not sure if the answers are still relevant given that the question was asked nearly 7 years ago but there's a few things.

Changing the node type or engine version is a Modify action and your data remains intact on your Elasticache clusters. I believe there was a doc that mentioned (if I find it, I will link it here) the process of Elasticache modifications take place. Essentially, Elasticache launches a new node on the backend with the modifications you've made and copies your data to it. Suppose the modification you make is a change in the engine version from 5.x to 6.x -

  1. Elasticache will launch new Redis nodes on the backend with Engine 6.x.
  2. As the node comes up, Elasticache will read keys from the 5.x node and copy data to 6.x
  3. When the copy is complete, Elasticache will make a change in the DNS records for your cluster's endpoints.

So, there will be some downtime depending on your application's DNS cache TTL config. For example, your application holds the DNS cache for 300 seconds, it can take it 300 seconds to refresh the DNS cache on your application/client-machine and during that time application might show some errors.

From the elasticache side, I do not think they provide any official SLA for this. But this doc[1] mentions it will only take a "few seconds" for this DNS to propogate (depending on engine versions).

Still, you can always take a snapshot of your cluster as a backup. If anything goes south, you can use snapshot to launch a new cluster with the same data.

Also, one more thing - AWS will never upgrade your engine versions by themselves. The maintenance window for your Elasitcache Cluster is for Security patches and small optimizations on the engines. They do not affect the engine versions.

Cheers!

[1] https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/AutoFailover.html

Edit - Once caveat to the engine version upgrade, they will upgrade it when they are discontinuing older versions like 2.x and 3.2.x . So, best to keep it latest generations.

Caddell answered 29/4, 2022 at 10:41 Comment(0)
A
4

Changing a cache engine version is a disruptive process which clears all cache data in the cluster. **

I don't now the requirements of your particular application. But if you can't lose your data and you need to do a major version upgrade, it would be advisable to migrate to a new cluster rather than upgrading the current setup.

** http://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/VersionManagement.html

Acetone answered 29/6, 2015 at 1:50 Comment(1)
The documentation link you provided now states that Redis engine upgrades will "make a best effort to retain your existing data and requires successful Redis replication".Leanora
I
3

It depends on your current version:

  • When upgrading to Redis 5.0.6 or above, the primary cluster continues to be available to service requests during the upgrade process (source).
  • Starting with Redis engine version 5.0.5, 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 (source); cluster available for reads during engine upgrades, writes are interrupted only for < 1sec with version 5.0.5 (source)
  • You can also upgrade your ElastiCache clusters with versions earlier than 5.0.5. The process involved is the same but may incur longer failover time during DNS propagation (30s-1m) (source, source).
Irritate answered 2/11, 2022 at 17:1 Comment(0)
B
2

As mentioned by Will above, the AWS answer has changed. and in theory you can do it without downtime. See:

https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/VersionManagement.html

The key points are in terms of downtime and impact on existing use:

The Amazon ElastiCache for Redis engine upgrade process is designed to make a best effort to retain your existing data and requires successful Redis replication.

...

For single Redis clusters and clusters with Multi-AZ disabled, we recommend that sufficient memory be made available to Redis as described in Ensuring That You Have Enough Memory to Create a Redis Snapshot. In these cases, the primary is unavailable to service requests during the upgrade process.

...

For Redis clusters with Multi-AZ enabled, we also recommend that you schedule engine upgrades during periods of low incoming write traffic. When upgrading to Redis 5.0.5 or above, the primary cluster continues to be available to service requests during the upgrade process. When upgrading to Redis 5.0.4 or below, you may notice a brief interruption of a few seconds associated with the DNS update.

There are no guarantees here so you will have to make your own decision about the risk of losing data if it fails

Burnejones answered 19/2, 2020 at 13:11 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.