Version upgrade behavior

This page describes how your Memorystore instance behaves during a version upgrade operation, how an upgrade operation can affect your application, and when you should run an upgrade operation. To learn how to upgrade an instance's Redis version, see Upgrading an instance's Redis version.

Depending on the instance's tier, running a version upgrade operation can have performance and storage implications for your application. There are also some limitations to upgrading instances based on the amount of memory that is currently in use.

Best practices for upgrading an instance's Redis version

  • We recommend exporting your instance data before running a version upgrade operation.

  • For Standard Tier instances, to increase the speed and reliability of your version upgrade operation, upgrade your instance during periods of low instance traffic. To learn how to monitor instance traffic, see Monitoring Redis instances.

  • When upgrading a Standard Tier instance, keep the instance write load to a minimum. A high write load can cause upgrade operations to take significantly longer, and can cause upgrades to fail.

Basic Tier instance upgrade behavior

Basic Tier instances block reads and writes while the version upgrade operation is ongoing. For Basic Tier instances that do not use the RDB snapshots feature, all data is flushed from the cache as a part of the upgrade operation. Instances using the RDB snapshots feature recover data from the snapshot after the upgrade is complete.

If your instance does not use RDB snapshots, but you want to preserve your data, you can export data, then import data after your version upgrade operation completes.

Standard Tier instance upgrade behavior

Instance data is preserved with high availability during a version upgrade operation. Instances use the following replica failover behavior:

First the upgrade is performed on the replica, or replicas. Then, replicas sync with the primary. Then, a failover occurs in which an upgraded replica is promoted to be the new primary. The old primary is then upgraded, and then it syncs with the new primary. As a result, a new node is now the primary, and all nodes received the version upgrade.

During the upgrade, connections to the instance are terminated. Applications should incorporate retry logic in the code to be able to reconnect to the new primary.

After the version upgrade operation completes, there may be stale or inconsistent data in the cache because of the asynchronous nature of Redis replication. Your application should be resilient enough to handle inconsistencies that arise during an upgrade operation.

Expired keys

When you upgrade a Standard Tier instance, expired keys are not synced. If you have expired keys in your Redis instance before you upgrade, you will have fewer keys after the upgrade operation completes.