Configure active geo-replication for Enterprise Azure Cache for Redis instances
In this article, you learn how to configure an active geo-replicated cache using the Azure portal.
Active geo-replication groups up to five instances of Enterprise Azure Cache for Redis into a single cache that spans across Azure regions. All instances act as the local, primary caches. An application decides which instance or instances to use for read and write requests.
Note
Data transfer between Azure regions is charged at standard bandwidth rates.
Tier | Basic, Standard | Premium | Enterprise, Enterprise Flash |
---|---|---|---|
Available | No | No | Yes |
The Premium tier of Azure Cache for Redis offers a version of geo-replication called passive geo-replication. Passive geo-replication provides an active-passive configuration.
There are a few restrictions when using active geo replication:
- Only the RediSearch and RedisJSON modules are supported
- On the Enterprise Flash tier, only the No Eviction eviction policy can be used. All eviction policies are supported on the Enterprise tier.
- Data persistence isn't supported because active geo-replication provides a superior experience.
- You can't add an existing (that is, running) cache to a geo-replication group. You can only add a cache to a geo-replication group when you create the cache.
- All caches within a geo-replication group must have the same configuration. For example, all caches must have the same SKU, capacity, eviction policy, clustering policy, modules, and TLS setting.
- You can't use the
FLUSHALL
andFLUSHDB
Redis commands when using active geo-replication. Prohibiting the commands prevents unintended deletion of data. Use the flush operation from the portal instead. - The E1 SKU doesn't support active geo-replication.
When creating a new Azure Cache for Redis resource, select the Advanced tab. Complete the first part of the form including clustering policy. For more information on choosing Clustering policy, see Clustering .
Select Configure to set up Active geo-replication.
Create a new replication group for a first cache instance. Or, select an existing one from the list.
Select Configure to finish.
Wait for the first cache to be created successfully. When complete, you see Configured set for Active geo-replication. Repeat the above steps for each cache instance in the geo-replication group.
To remove a cache instance from an active geo-replication group, you just delete the instance. The remaining instances then reconfigure themselves automatically.
In case one of the caches in your replication group is unavailable due to region outage, you can forcefully remove the unavailable cache from the replication group. After you apply Force-unlink to a cache, you can't sync any data that is written to that cache back to the replication group after force-unlinking.
You should remove the unavailable cache because the remaining caches in the replication group start storing the metadata that hasn’t been shared to the unavailable cache. When this happens, the available caches in your replication group might run out of memory.
Go to Azure portal and select one of the caches in the replication group that is still available.
Select to Active geo-replication in the Resource menu on the left to see the settings in the working pane.
Select the cache that you need to force-unlink by checking the box.
Select Force unlink and then OK to confirm.
Once the affected region's availability is restored, you need to delete the affected cache, and recreate it to add it back to your replication group.
Use the Azure CLI to create a new cache and geo-replication group, or to add a new cache to an existing geo-replication group. For more information, see az redisenterprise create.
This example creates a new Azure Cache for Redis Enterprise E10 cache instance called Cache1 in the East US region. Then, the cache is added to a new active geo-replication group called replicationGroup:
az redisenterprise create --location "East US" --cluster-name "Cache1" --sku "Enterprise_E10" --resource-group "myResourceGroup" --group-nickname "replicationGroup" --linked-databases id="/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/myResourceGroup/providers/Microsoft.Cache/redisEnterprise/Cache1/databases/default"
To configure active geo-replication properly, the ID of the cache instance being created must be added with the --linked-databases
parameter. The ID is in the format:
/subscriptions/<your-subscription-ID>/resourceGroups/<your-resource-group-name>/providers/Microsoft.Cache/redisEnterprise/<your-cache-name>/databases/default
This example creates a new Enterprise E10 cache instance called Cache2 in the West US region. Then, the script adds the cache to the replicationGroup
active geo-replication group create in a previous procedure. This way, it's linked in an active-active configuration with Cache1.
az redisenterprise create --location "West US" --cluster-name "Cache2" --sku "Enterprise_E10" --resource-group "myResourceGroup" --group-nickname "replicationGroup" --linked-databases id="/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/myResourceGroup/providers/Microsoft.Cache/redisEnterprise/Cache1/databases/default" --linked-databases id="/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/myResourceGroup/providers/Microsoft.Cache/redisEnterprise/Cache2/databases/default"
As before, you need to list both Cache1 and Cache2 using the --linked-databases
parameter.
Use Azure PowerShell to create a new cache and geo-replication group, or to add a new cache to an existing geo-replication group. For more information, see New-AzRedisEnterpriseCache.
This example creates a new Azure Cache for Redis Enterprise E10 cache instance called Cache1 in the East US region. Then, the cache is added to a new active geo-replication group called replicationGroup:
New-AzRedisEnterpriseCache -Name "Cache1" -ResourceGroupName "myResourceGroup" -Location "East US" -Sku "Enterprise_E10" -GroupNickname "replicationGroup" -LinkedDatabase '{id:"/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/myResourceGroup/providers/Microsoft.Cache/redisEnterprise/Cache1/databases/default"}'
To configure active geo-replication properly, the ID of the cache instance being created must be added with the -LinkedDatabase
parameter. The ID is in the format:
/subscriptions/<your-subscription-ID>/resourceGroups/<your-resource-group-name>/providers/Microsoft.Cache/redisEnterprise/<your-cache-name>/databases/default
This example creates a new Enterprise E10 cache instance called Cache2 in the West US region. Then, the script adds the cache to the replicationGroup active geo-replication group created in the previous procedure. After the running the command, the two caches, Cache1 and Cache2, are linked in an active-active configuration.
New-AzRedisEnterpriseCache -Name "Cache2" -ResourceGroupName "myResourceGroup" -Location "West US" -Sku "Enterprise_E10" -GroupNickname "replicationGroup" -LinkedDatabase '{id:"/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/myResourceGroup/providers/Microsoft.Cache/redisEnterprise/Cache1/databases/default"}', '{id:"/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/myResourceGroup/providers/Microsoft.Cache/redisEnterprise/Cache2/databases/default"}'
As before, you need to list both Cache1 and Cache2 using the -LinkedDatabase
parameter.
It's possible to scale instances that are configured to use active geo-replication. However, a geo-replication group with a mix of different cache sizes can introduce problems. To prevent these issues from occurring, all caches in a geo replication group need to be the same size and capacity.
Because it's difficult to simultaneously scale all instances in the geo-replication group, Azure Cache for Redis has a locking mechanism. If you scale one instance in a geo-replication group, the underlying VM is scaled, but the memory available is capped at the original size until the other instances are scaled up as well. Any other scaling operations for the remaining instances are locked until they match the same configuration as the first cache to be scaled.
For example, you might have three instances in your geo-replication group, all Enterprise E10 instances:
Instance Name | Redis00 | Redis01 | Redis02 |
---|---|---|---|
Type | Enterprise E10 | Enterprise E10 | Enterprise E10 |
Let's say you want to scale up each instance in this geo-replication group to an Enterprise E20 instance. You would first scale one of the caches up to an E20:
Instance Name | Redis00 | Redis01 | Redis02 |
---|---|---|---|
Type | Enterprise E20 | Enterprise E10 | Enterprise E10 |
At this point, the Redis01
and Redis02
instances can only scale up to an Enterprise E20 instance. All other scaling operations are blocked.
Note
The Redis00
instance is not blocked from scaling further at this point. But it will be blocked once either Redis01
or Redis02
is scaled to be an Enterprise E20.
Once each instance is scaled to the same tier and size, all scaling locks are removed:
Instance Name | Redis00 | Redis01 | Redis02 |
---|---|---|---|
Type | Enterprise E20 | Enterprise E20 | Enterprise E20 |
Due to the potential for inadvertent data loss, you can't use the FLUSHALL
and FLUSHDB
Redis commands with any cache instance residing in a geo-replication group. Instead, use the Flush Cache(s) button located at the top of the Active geo-replication working pane.
The Azure CLI and PowerShell can also be used to trigger a flush operation. For more information on using Azure CLI, see az redisenterprise database flush. For more information on using PowerShell, see Invoke-AzRedisEnterpriseCacheDatabaseFlush.
Important
Be careful when using the Flush Caches feature. Selecting the button removes all data from the current cache and from ALL linked caches in the geo-replication group.
Manage access to the feature using Azure role-based access control. Only authorized users should be given access to flush all caches.
Learn more about Azure Cache for Redis features.