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
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 Google Cloud console.
Instance scaling behavior
During scaling for both Basic and Standard Tier instances, data is preserved. When you scale an instance, the instance undergoes a short connection reset of a couple of minutes or less. We recommend that applications incorporate retry logic in the code so that they can reconnect to the instance. The IP address and connection string remain the same.
Additionally, there might be a gap of several minutes when the core metrics for the instance don't appear. Aside from the brief connection reset, the instance remains available during this time, and metrics reporting resumes after the time interval completes. There might be a small amount of stale or inconsistent data that doesn't write or update to the cache for the short amount of time that the instance is unavailable.
If you issue a write during the connection break, Memorystore
returns the error READONLY You can't write against a read only replica. This
error is transient, and only lasts a few seconds. It resolves once the scaling
operation completes.
Write load when scaling
You should scale an instance during a period of low instance traffic to minimize the performance impact on your application. A high write load, or high memory pressure, can cause an scaling operation to take significantly longer and can cause the operation to fail. For more information see Scaling and version upgrade operations.
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.