Configure geo-replication for Premium Azure Cache for Redis instances

In this article, you'll learn how to configure a geo-replicated Azure Cache using the Azure portal.

Geo-replication links together two Premium Azure Cache for Redis instances and creates a data replication relationship. These cache instances are usually located in different Azure regions, though they aren't required to. One instance acts as the primary, and the other as the secondary. The primary handles read and write requests and propagates changes to the secondary. This process continues until the link between the two instances is removed.

Note

Geo-replication is designed as a disaster-recovery solution.

Geo-replication prerequisites

To configure geo-replication between two caches, the following prerequisites must be met:

  • Both caches are Premium tier caches.
  • Both caches are in the same Azure subscription.
  • The secondary linked cache is either the same cache size or a larger cache size than the primary linked cache.
  • Both caches are created and in a running state.

Note

Data transfer between Azure regions will be charged at standard bandwidth rates.

Some features aren't supported with geo-replication:

  • Zone Redundancy isn't supported with geo-replication.
  • Persistence isn't supported with geo-replication.
  • Clustering is supported if both caches have clustering enabled and have the same number of shards.
  • Caches in the same Virtual Network (VNet) are supported.
  • Caches in different VNets are supported with caveats. See Can I use geo-replication with my caches in a VNet? for more information.

After geo-replication is configured, the following restrictions apply to your linked cache pair:

  • The secondary linked cache is read-only; you can read from it, but you can't write any data to it. If you choose to read from the Geo-Secondary instance, it is important to note that whenever a full data sync is happening between the Geo-Primary and the Geo-Secondary (happens when either Geo-Primary or Geo-Secondary is updated and on some reboot scenarios as well), the Geo-Secondary instance will throw errors (stating that a full data sync is in progress) on any Redis operation against it until the full data sync between Geo-Primary and Geo-Secondary is complete. Applications reading from Geo-Secondary should be built to fall back to the Geo-Primary whenever the Geo-Secondary is throwing such errors.
  • Any data that was in the secondary linked cache before the link was added is removed. If the geo-replication is later removed however, the replicated data remains in the secondary linked cache.
  • You can't scale either cache while the caches are linked.
  • You can't change the number of shards if the cache has clustering enabled.
  • You can't enable persistence on either cache.
  • You can Export from either cache.
  • You can't Import into the secondary linked cache.
  • You can't delete either linked cache, or the resource group that contains them, until you unlink the caches. For more information, see Why did the operation fail when I tried to delete my linked cache?
  • If the caches are in different regions, network egress costs apply to the data moved across regions. For more information, see How much does it cost to replicate my data across Azure regions?
  • Automatic failover doesn't occur between the primary and secondary linked cache. For more information and information on how to failover a client application, see How does failing over to the secondary linked cache work?
  1. To link two caches together for geo-replication, fist click Geo-replication from the Resource menu of the cache that you intend to be the primary linked cache. Next, click Add cache replication link from Geo-replication on the left.

    Cache geo-replication menu

  2. Select the name of your intended secondary cache from the Compatible caches list. If your secondary cache isn't displayed in the list, verify that the Geo-replication prerequisites for the secondary cache are met. To filter the caches by region, select the region in the map to display only those caches in the Compatible caches list.

    Select compatible cache

    You can also start the linking process or view details about the secondary cache by using the context menu.

    Geo-replication context menu

  3. Select Link to link the two caches together and begin the replication process.

    Link caches

  4. You can view the progress of the replication process using Geo-replication on the left.

    Linking status

    You can also view the linking status on the left, using Overview, for both the primary and secondary caches.

    Screenshot that highlights how to view the linking status for the primary and secondary caches.

    Once the replication process is complete, the Link status changes to Succeeded.

    Cache status

    The primary linked cache remains available for use during the linking process. The secondary linked cache isn't available until the linking process completes.

  1. To remove the link between two caches and stop geo-replication, click Unlink caches from the Geo-replication on the left .

    Unlink caches

    When the unlinking process completes, the secondary cache is available for both reads and writes.

Note

When the geo-replication link is removed, the replicated data from the primary linked cache remains in the secondary cache.

Geo-replication FAQ

Can I use geo-replication with a Standard or Basic tier cache?

No, geo-replication is only available for Premium tier caches.

Is my cache available for use during the linking or unlinking process?

  • When linking, the primary linked cache remains available while the linking process completes.
  • When linking, the secondary linked cache isn't available until the linking process completes.
  • When unlinking, both caches remain available while the unlinking process completes.

No, you can only link two caches together.

No, both caches must be in the same Azure subscription.

Yes, as long as the secondary linked cache is larger than the primary linked cache.

Can I use geo-replication with clustering enabled?

Yes, as long as both caches have the same number of shards.

Can I use geo-replication with my caches in a VNet?

Yes, geo-replication of caches in VNets is supported with caveats:

  • Geo-replication between caches in the same VNet is supported.
  • Geo-replication between caches in different VNets is also supported.
    • If the VNets are in the same region, you can connect them using VNet peering or a VPN Gateway VNet-to-VNet connection.
    • If the VNets are in different regions, geo-replication using VNet peering is supported, but a client VM in VNet 1 (region 1) is not able to access the cache in VNet 2 (region 2) using it's DNS name because of a constraint with Basic internal load balancers. For more information about VNet peering constraints, see Virtual Network - Peering - Requirements and constraints. We recommend to use a VPN Gateway VNet-to-VNet connection.

Using this Azure template, you can quickly deploy two geo-replicated caches into a VNet connected with a VPN Gateway VNet-to-VNet connection.

What is the replication schedule for Redis geo-replication?

Replication is continuous and asynchronous. It doesn't happen on a specific schedule. All the writes done to the primary are instantaneously and asynchronously replicated on the secondary.

How long does geo-replication replication take?

Replication is incremental, asynchronous, and continuous and the time taken isn't much different from the latency across regions. Under certain circumstances, the secondary cache can be required to do a full sync of the data from the primary. The replication time in this case is depends on a number of factors like: load on the primary cache, available network bandwidth, and inter-region latency. We have found replication time for a full 53-GB geo-replicated pair can be anywhere between 5 to 10 minutes.

Is the replication recovery point guaranteed?

For caches in a geo-replicated mode, persistence is disabled. If a geo-replicated pair is unlinked, such as a customer-initiated failover, the secondary linked cache keeps its synced data up to that point of time. No recovery point is guaranteed in such situations.

To obtain a recovery point, Export from either cache. You can later Import into the primary linked cache.

Can I use PowerShell or Azure CLI to manage geo-replication?

Yes, geo-replication can be managed using the Azure portal, PowerShell, or Azure CLI. For more information, see the PowerShell docs or Azure CLI docs.

How much does it cost to replicate my data across Azure regions?

When using geo-replication, data from the primary linked cache is replicated to the secondary linked cache. There's no charge for the data transfer if the two linked caches are in the same region. If the two linked caches are in different regions, the data transfer charge is the network egress cost of data moving across either region. For more information, see Bandwidth Pricing Details.

Why did the operation fail when I tried to delete my linked cache?

Geo-replicated caches and their resource groups can't be deleted while linked until you remove the geo-replication link. If you attempt to delete the resource group that contains one or both of the linked caches, the other resources in the resource group are deleted, but the resource group stays in the deleting state and any linked caches in the resource group remain in the running state. To completely delete the resource group and the linked caches within it, unlink the caches as described in Remove a geo-replication link.

What region should I use for my secondary linked cache?

In general, it's recommended for your cache to exist in the same Azure region as the application that accesses it. For applications with separate primary and fallback regions, it's recommended your primary and secondary caches exist in those same regions. For more information about paired regions, see Best Practices – Azure Paired regions.

How does failing over to the secondary linked cache work?

Automatic failover across Azure regions isn't supported for geo-replicated caches. In a disaster-recovery scenario, customers should bring up the entire application stack in a coordinated manner in their backup region. Letting individual application components decide when to switch to their backups on their own can negatively impact performance.

One of the key benefits of Redis is that it's a very low-latency store. If the customer's main application is in a different region than its cache, the added round-trip time would have a noticeable impact on performance. For this reason, we avoid failing over automatically because of transient availability issues.

To start a customer-initiated failover, first unlink the caches. Then, change your Redis client to use the connection endpoint of the (formerly linked) secondary cache. When the two caches are unlinked, the secondary cache becomes a regular read-write cache again and accepts requests directly from Redis clients.

Can I configure a firewall with geo-replication?

Yes, you can configure a firewall with geo-replication. For geo-replication to function alongside a firewall, ensure that the secondary cache's IP address is added to the primary cache's firewall rules.

Next steps

Learn more about Azure Cache for Redis features.