Instance scaling behavior

This page describes how your Memorystore for Redis instance behaves during scaling. To learn how to scale a Redis instance, see Scaling Redis Instances.

Depending on the instance's tier, scaling an instance has performance and storage implications for your application. There are also some limitations to scaling instances based on the amount of memory that is currently in use. This page describes how scaling an instance can affect your application and when you can scale an instance.

Best practices for scaling an instance

  • We recommend exporting your instance data before scaling your instance.

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

  • When reducing a Standard Tier instance's capacity, you must choose a size greater than the amount of data being stored or scaling fails.

    • For example, if your have a 10 GB instance that has 5.5 GB of data stored in it, you can resize the instance to a minimum of 6 GB. The amount of storage your instance uses is visible on its details page in the Cloud Console.

Basic Tier scaling behavior

Basic Tier instances block reads and writes while the instance is resized to the desired capacity. After the instance is resized, all data is flushed from the cache. Scale an instance during a period of low instance traffic to minimize the performance impact on your application.

We recommend exporting a backup of your instance before scaling, and importing the backup once the scaling operation is complete.

Standard Tier scaling behavior

Scale Standard Tier instances during a period of low activity to minimize the performance impact scaling has on your application.

Standard Tier instances experience almost no downtime during the scaling process because all Standard Tier instances have a primary node and a replica node. During scaling, the replica is resized first, then synced with the primary. Once the new replica has caught up with the new primary, the new primary fails over to the new replica.

During the failover, connections to the instance are terminated. Applications should incorporate retry logic in the code to be able to reconnect to the new primary node. Finally, the old primary node instance is resized.

After scaling is complete, there may be stale or inconsistent data in the cache because of the asynchronous nature of Redis replication. The application should be resilient enough to handle inconsistencies that arise during failover.

Write load during scaling

When scaling a Standard Tier instance, keep the instance write load to a minimum. A high write load can cause scaling to take significantly longer and can cause the scaling operation to fail.

Expired keys

When you scale a Standard Tier instance, expired keys are not synced. If you have expired keys in your Redis instance before you scale, you will have fewer keys after the instance is scaled.