Scale up and down using the Azure portal
To scale your cache, browse to the cache in the Azure portal and select Scale from the Resource menu.
Choose a pricing tier in the working pane and then choose Select.
While the cache is scaling to the new tier, a Scaling Redis Cache notification is displayed.
When scaling is complete, the status changes from Scaling to Running.
Note
When you scale a cache up or down using the portal, both maxmemory-reserved and maxfragmentationmemory-reserved settings automatically scale in proportion to the cache size.
For example, if maxmemory-reserved is set to 3 GB on a 6-GB cache, and you scale to 12-GB cache, the settings automatically get updated to 6 GB during scaling.
When you scale down, the reverse happens.
Scale up and down using PowerShell
You can scale your Azure Cache for Redis instances with PowerShell by using the Set-AzRedisCache cmdlet when the Sizeor Sku properties are modified. The following example shows how to scale a cache named myCache to a 6-GB cache in the same tier.
Set-AzRedisCache -ResourceGroupName myGroup -Name myCache -Size 6GB
For more information on scaling with PowerShell, see To scale an Azure Cache for Redis using PowerShell.
Scale up and down using Azure CLI
To scale your Azure Cache for Redis instances using Azure CLI, call the az redis update command. Use the sku.capcity property to scale within a tier, for example from a Standard C0 to Standard C1 cache:
az redis update --cluster-name myCache --resource-group myGroup --set "sku.capacity"="2"
Use the 'sku.name' and 'sku.family' properties to scale up to a different tier, for instance from a Standard C1 cache to a Premium P1 cache:
az redis update --cluster-name myCache --resource-group myGroup --set "sku.name"="Premium" "sku.capacity"="1" "sku.family"="P"
For more information on scaling with Azure CLI, see Change settings of an existing Azure Cache for Redis.
Note
When you scale a cache up or down programatically (e.g. using PowerShell or Azure CLI), any maxmemory-reserved or maxfragmentationmemory-reserved are ignored as part of the update request. Only your scaling change is honored. You can update these memory settings after the scaling operation has completed.
Create a new cache that is scaled out using clustering
Clustering is enabled during cache creation from the working pane, when you create a new Azure Cache for Redis.
Use the Create an open-source Redis cache quickstart guide to start creating a new cache using the Azure portal.
In the Advanced tab for a premium cache instance, configure the settings for non-TLS port, clustering, and data persistence. To enable clustering, select Enable.
You can have up to 30 shards in the cluster. After selecting Enable, slide the slider or type a number between 1 and 30 for Shard count and select OK.
Each shard is a primary/replica cache pair managed by Azure. The total size of the cache is calculated by multiplying the number of shards by the cache size selected in the pricing tier.
Once the cache is created, you connect to it and use it just like a nonclustered cache. Redis distributes the data throughout the Cache shards. If diagnostics is enabled, metrics are captured separately for each shard, and can be viewed in Azure Cache for Redis using the Resource menu.
Finish creating the cache using the quickstart guide.
It takes a while for the cache to create. You can monitor progress on the Azure Cache for Redis Overview page. When Status shows as Running, the cache is ready to use.
For sample code on working with clustering with the StackExchange.Redis client, see the clustering.cs portion of the Hello World sample.
Scale a running Premium cache in or out
To change the cluster size on a premium cache that you created earlier, and is already running with clustering enabled, select Cluster size from the Resource menu.
To change the cluster size, use the slider or type a number between 1 and 30 in the Shard count text box. Then, select OK to save.
Increasing the cluster size increases max throughput and cache size. Increasing the cluster size doesn't increase the max. connections available to clients.
Scale out and in using PowerShell
You can scale out your Azure Cache for Redis instances with PowerShell by using the Set-AzRedisCache cmdlet when the ShardCount property is modified. The following example shows how to scale out a cache named myCache out to use three shards (that is, scale out by a factor of three)
Set-AzRedisCache -ResourceGroupName myGroup -Name myCache -ShardCount 3
For more information on scaling with PowerShell, see To scale an Azure Cache for Redis using PowerShell.
Scale out and in using Azure CLI
To scale your Azure Cache for Redis instances using Azure CLI, call the az redis update command and use the shard-count property. The following example shows how to scale out a cache named myCache to use three shards (that is, scale out by a factor of three).
az redis update --cluster-name myCache --resource-group myGroup --set shard-count=3
For more information on scaling with Azure CLI, see Change settings of an existing Azure Cache for Redis.
Note
When you scale a cache up or down programmatically (e.g. using PowerShell or Azure CLI), any maxmemory-reserved or maxfragmentationmemory-reserved are ignored as part of the update request. Only your scaling change is honored. You can update these memory settings after the scaling operation has completed.
Note
Scaling a cluster runs the MIGRATE command, which is an expensive command. For minimal impact, consider running this operation during non-peak hours. During the migration process, you see a spike in server load. Scaling a cluster is a long running process and the amount of time taken depends on the number of keys and size of the values associated with those keys.
Scaling FAQ
The following list contains answers to commonly asked questions about Azure Cache for Redis scaling.
Can I scale to, from, or within a Premium cache?
- You can't scale from a Premium cache down to a Basic or Standard pricing tier.
- You can scale from one Premium cache pricing tier to another.
- You can't scale from a Basic cache directly to a Premium cache. First, scale from Basic to Standard in one scaling operation, and then from Standard to Premium in a later scaling operation.
- If you enabled clustering when you created your Premium cache, you can change the cluster size. If your cache was created without clustering enabled, you can configure clustering at a later time.
After scaling, do I have to change my cache name or access keys?
No, your cache name and keys are unchanged during a scaling operation.
How does scaling work?
- When you scale a Basic cache to a different size, it's shut down, and a new cache is provisioned using the new size. During this time, the cache is unavailable and all data in the cache is lost.
- When you scale a Basic cache to a Standard cache, a replica cache is provisioned and the data is copied from the primary cache to the replica cache. The cache remains available during the scaling process.
- When you scale a Standard, Premium cache to a different size, one of the replicas is shut down and reprovisioned to the new size and the data transferred over, and then the other replica does a failover before it's reprovisioned, similar to the process that occurs during a failure of one of the cache nodes.
- When you scale out a clustered cache, new shards are provisioned and added to the Redis server cluster. Data is then resharded across all shards.
- When you scale in a clustered cache, data is first resharded and then cluster size is reduced to required shards.
- In some cases, such as scaling or migrating your cache to a different cluster, the underlying IP address of the cache can change. The DNS record for the cache changes and is transparent to most applications. However, if you use an IP address to configure the connection to your cache, or to configure NSGs, or firewalls allowing traffic to the cache, your application might have trouble connecting sometime after the DNS record updates.
Do I lose data from my cache during scaling?
- When you scale a Basic cache to a new size, all data is lost and the cache is unavailable during the scaling operation.
- When you scale a Basic cache to a Standard cache, the data in the cache is typically preserved.
- When you scale a Standard, Premium cache to a larger size, all data is typically preserved. When you scale a Standard or Premium cache to a smaller size, data can be lost if the data size exceeds the new smaller size when it's scaled down. If data is lost when scaling down, keys are evicted using the allkeys-lru eviction policy.
Can I use all the features of Premium tier after scaling?
No, some features can only be set when you create a cache in Premium tier, and are not available after scaling.
These features cannot be added after you create the Premium cache:
- VNet injection
- Adding zone redundancy
- Using multiple replicas per primary
To use any of these features, you must create a new cache instance in the Premium tier.
Is my custom databases setting affected during scaling?
If you configured a custom value for the databases setting during cache creation, keep in mind that some pricing tiers have different databases limits. Here are some considerations when scaling in this scenario:
- When you scale to a pricing tier with a lower
databases limit than the current tier:
- If you're using the default number of
databases, which is 16 for all pricing tiers, no data is lost.
- If you're using a custom number of
databases that falls within the limits for the tier to which you're scaling, this databases setting is kept and no data is lost.
- If you're using a custom number of
databases that exceeds the limits of the new tier, the databases setting is lowered to the limits of the new tier and all data in the removed databases is lost.
- When you scale to a pricing tier with the same or higher
databases limit than the current tier, your databases setting is kept and no data is lost.
While Standard, Premium, caches have a SLA for availability, there's no SLA for data loss.
Will my cache be available during scaling?
- Standard, Premium caches remain available during the scaling operation. However, connection blips can occur while scaling these caches, and also while scaling from Basic to Standard caches. These connection blips are expected to be small and redis clients can generally re-establish their connection instantly.
- Basic caches are offline during scaling operations to a different size. Basic caches remain available when scaling from Basic to Standard but might experience a small connection blip. If a connection blip occurs, Redis clients can generally re-establish their connection instantly.
Are there scaling limitations with geo-replication?
With passive geo-replication configured, you might notice that you can’t scale a cache or change the shards in a cluster. A geo-replication link between two caches prevents you from scaling operation or changing the number of shards in a cluster. You must unlink the cache to issue these commands. For more information, see Configure Geo-replication.
Operations that aren't supported
- You can't scale from a higher pricing tier to a lower pricing tier.
- You can't scale from a Premium cache down to a Standard or a Basic cache.
- You can't scale from a Standard cache down to a Basic cache.
- You can scale from a Basic cache to a Standard cache but you can't change the size at the same time. If you need a different size, you can do a scaling operation to the size you want at a later time.
- You can't scale from a Basic cache directly to a Premium cache. First scale from Basic to Standard in one scaling operation, and then scale from Standard to Premium in a later operation.
- You can't scale from a larger size down to the C0 (250 MB) size.
If a scaling operation fails, the service tries to revert the operation, and the cache will revert to the original size.
How long does scaling take?
Scaling time depends on a few factors. Here are some factors that can affect how long scaling takes.
- Amount of data: Larger amounts of data take a longer time to be replicated
- High write requests: Higher number of writes mean more data replicates across nodes or shards
- High server load: Higher server load means Redis server is busy and has limited CPU cycles to complete data redistribution
Generally, when you scale a cache with no data, it takes approximately 20 minutes. For clustered caches, scaling takes approximately 20 minutes per shard with minimal data.
How can I tell when scaling is complete?
In the Azure portal, you can see the scaling operation in progress. When scaling is complete, the status of the cache changes to Running.
Do I need to make any changes to my client application to use clustering?
How are keys distributed in a cluster?
Per the Redis documentation on Keys distribution model: The key space is split into 16,384 slots. Each key is hashed and assigned to one of these slots, which are distributed across the nodes of the cluster. You can configure which part of the key is hashed to ensure that multiple keys are located in the same shard using hash tags.
- Keys with a hash tag - if any part of the key is enclosed in
{ and }, only that part of the key is hashed for the purposes of determining the hash slot of a key. For example, the following three keys would be located in the same shard: {key}1, {key}2, and {key}3 since only the key part of the name is hashed. For a complete list of keys hash tag specifications, see Keys hash tags.
- Keys without a hash tag - the entire key name is used for hashing, resulting in a statistically even distribution across the shards of the cache.
For best performance and throughput, we recommend distributing the keys evenly. If you're using keys with a hash tag, it's the application's responsibility to ensure the keys are distributed evenly.
For more information, see Keys distribution model, Redis Cluster data sharding, and Keys hash tags.
For sample code about working with clustering and locating keys in the same shard with the StackExchange.Redis client, see the clustering.cs portion of the Hello World sample.
What is the largest cache size I can create?
The largest cache size you can have is 4.5 TB. This result is a clustered F1500 cache with capacity 9. For more information, see Azure Cache for Redis Pricing.
Do all Redis clients support clustering?
Many clients libraries support Redis clustering but not all. Check the documentation for the library you're using to verify you're using a library and version that support clustering. StackExchange.Redis is one library that does support clustering, in its newer versions. For more information on other clients, see the Playing with the cluster section of the Redis cluster tutorial.
The Redis clustering protocol requires each client to connect to each shard directly in clustering mode, and also defines new error responses such as 'MOVED' na 'CROSSSLOTS'. When you attempt to use a client library that doesn't support clustering, with a cluster mode cache, the result can be many MOVED redirection exceptions, or just break your application, if you're doing cross-slot multi-key requests.
Note
If you're using StackExchange.Redis as your client, verify that you are using the latest version of StackExchange.Redis 1.0.481 or later for clustering to work correctly. For more information on any issues with move exceptions, see move exceptions.
How do I connect to my cache when clustering is enabled?
You can connect to your cache using the same endpoints, ports, and keys that you use when connecting to a cache that doesn't have clustering enabled. Redis manages the clustering on the backend so you don't have to manage it from your client.
Can I directly connect to the individual shards of my cache?
The clustering protocol requires the client to make the correct shard connections, so the client should make share connections for you. With that said, each shard consists of a primary/replica cache pair, collectively known as a cache instance. You can connect to these cache instances using the Redis-CLI utility in the unstable branch of the Redis repository at GitHub. This version implements basic support when started with the -c switch. For more information, see Playing with the cluster on https://redis.io in the Redis cluster tutorial.
You need to use the -p switch to specify the correct port to connect to. Use the CLUSTER NODES command to determine the exact ports used for the primary and replica nodes. The following port ranges are used:
- For non-TLS Premium tier caches, ports are available in the
130XX range
- For TLS enabled Premium tier caches, ports are available in the
150XX range
Yes. First, ensure that your cache is in the Premium tier by scaling it up. Next, you can see the cluster configuration options, including an option to enable cluster. Change the cluster size after the cache is created, or after you have enabled clustering for the first time.
Important
You can't undo enabling clustering. And a cache with clustering enabled and only one shard behaves differently than a cache of the same size with no clustering.
Clustering is only available for Premium caches.
Can I use clustering with the Redis ASP.NET Session State and Output Caching providers?
I'm getting MOVE exceptions when using StackExchange.Redis and clustering, what should I do?
If you're using StackExchange.Redis and receive MOVE exceptions when using clustering, ensure that you're using StackExchange.Redis 1.1.603 or later. For instructions on configuring your .NET applications to use StackExchange.Redis, see Configure the cache clients.
Next steps