如何为 Azure Redis 缓存设置异地复制How to set up geo-replication for Azure Cache for Redis

“异地复制”提供一种用于链接两个高级层 Azure Redis 缓存实例的机制。Geo-replication provides a mechanism for linking two Premium tier Azure Cache for Redis instances. 一个缓存选作主链接缓存,另一个缓存指定为辅助链接缓存。One cache is chosen as the primary linked cache, and the other as the secondary linked cache. 辅助链接缓存将变为只读,写入主缓存的数据将复制到辅助链接缓存。The secondary linked cache becomes read-only, and data written to the primary cache is replicated to the secondary linked cache. 主缓存实例和辅助缓存实例之间的数据传输受 TLS 保护。Data transfer between the primary and secondary cache instances is secured by TLS. 异地复制可用于设置跨两个 Azure 区域的缓存。Geo-replication can be used to set up a cache that spans two Azure regions. 本文提供了为高级层 Azure Redis 缓存实例配置异地复制的指南。This article provides a guide to configuring geo-replication for your Premium tier Azure Cache for Redis instances.

备注

异地复制设计为灾难恢复解决方案。Geo-replication is designed as a disaster-recovery solution. 默认情况下,应用程序将写入主要区域并从中进行读取。By default, your application will write to and read from the primary region. 可以选择将其配置为从次要区域进行读取。It can optionally be configured to read from the secondary region. 如果应用程序的其余部分保留在主要区域中,则出于担心区域之间的网络延迟会增加的原因,异地复制不会提供自动故障转移。Geo-replication doesn't provide automatic failover due to concerns over added network latency between regions if the rest of your application remains in the primary region. 需要通过取消链接辅助缓存来管理和启动故障转移。You'll need to manage and initiate the failover by unlinking the secondary cache. 这将使它提升为新的主实例。This will promote it to be the new primary instance.

异地复制先决条件Geo-replication prerequisites

若要在两个缓存之间配置异地复制,必须满足以下先决条件:To configure geo-replication between two caches, the following prerequisites must be met:

  • 这两个缓存是高级层缓存。Both caches are Premium tier caches.
  • 这两个缓存在同一 Azure 订阅中。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.

异地复制不支持某些功能:Some features aren'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.
  • 支持同一 VNET 中的缓存。Caches in the same VNET are supported.
  • 也支持不同 VNET 中的缓存,但需要注意一些问题。Caches in different VNETs are supported with caveats. 有关详细信息,请参阅当缓存位于 VNET 中时是否可以使用异地复制?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.
  • 添加链接前辅助链接缓存中的任何数据都会被删除。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. 有关详细信息,请参阅跨 Azure 区域复制数据的费用是多少?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 the Geo-replication blade.

    添加链接

  2. 在“兼容的缓存”列表中,单击所需辅助缓存的名称。Click 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, click the region in the map to display only those caches in the Compatible caches list.

    异地复制兼容缓存

    还可以使用上下文菜单启动链接过程或查看辅助缓存的详细信息。You can also start the linking process or view details about the secondary cache by using the context menu.

    异地复制上下文菜单

  3. 单击“链接”将两个缓存链接在一起并开始复制过程。Click Link to link the two caches together and begin the replication process.

    链接缓存

  4. 可以在“异地复制”边栏选项卡上查看复制过程的进度。You can view the progress of the replication process on the Geo-replication blade.

    链接状态

    还可以在主缓存和辅助缓存的“概述”边栏选项卡上查看链接状态。You can also view the linking status on the Overview blade for both the primary and secondary caches.

    缓存状态

    复制过程完成后,“链接状态”改为“成功”。Once the replication process is complete, the Link status changes to Succeeded.

    缓存状态

    在链接过程中,主链接缓存仍然可用。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 blade.

    取消链接缓存

    取消链接过程完成后,辅助缓存可用于读取和写入。When the unlinking process completes, the secondary cache is available for both reads and writes.

备注

在删除异地复制链接后,从主链接缓存复制的数据保留在辅助缓存中。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.

不可以,这两个缓存必须在同一 Azure 订阅中。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.

当缓存位于 VNET 中时是否可以使用异地复制?Can I use geo-replication with my caches in a VNET?

可以,支持对 VNET 中的缓存进行异地复制,但需要注意以下问题:Yes, geo-replication of caches in VNETs is supported with caveats:

  • 支持在同一 VNET 中的缓存间进行异地复制。Geo-replication between caches in the same VNET is supported.
  • 也支持在不同 VNET 中的缓存之间进行异地复制。Geo-replication between caches in different VNETs is also supported.

使用此 Azure 模板可以快速将两个异地复制的缓存部署到通过 VPN 网关 VNET 到 VNET 连接进行连接的 VNET 中。Using this Azure template, you can quickly deploy two geo-replicated caches into a VNET connected with a VPN Gateway VNET-to-VNET connection.

什么是 Redis 异地复制的复制计划?What is the replication schedule for Redis geo-replication?

复制是持续异步进行的,而不是按特定的计划进行。Replication is continuous and asynchronous and 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 may be required to do a full sync of the data from the primary. 在这种情况下,复制时间取决于多个因素,例如:主缓存上的负载、可用网络带宽和区域间的延迟。The replication time in this case is dependent on number of factors like: load on the primary cache, available network bandwidth, and inter-region latency. 我们发现,在一个异地复制对之间完整复制 53 GB 的内容可能需要 5-10 分钟时间。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.

是否可以使用 PowerShell 或 Azure CLI管理异地复制?Can I use PowerShell or Azure CLI to manage geo-replication?

是的,可以使用 Azure 门户、PowerShell 或 Azure CLI 管理异地复制。Yes, geo-replication can be managed using the Azure portal, PowerShell, or Azure CLI. 有关详细信息,请参阅 PowerShell 文档Azure CLI 文档For more information, see the PowerShell docs or Azure CLI docs.

跨 Azure 区域复制数据的费用是多少?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. 如果尝试删除包含一个或两个链接缓存的资源组,则会删除该资源组中的其他资源,但该资源组保持 deleting 状态,而资源组中的任意链接缓存则保持 running 状态。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?

一般而言,建议将缓存放置在应用程序所在的同一 Azure 区域,便于应用程序访问。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. 有关配对区域的详细信息,请参阅最佳做法 - Azure 配对区域For more information about paired regions, see Best Practices - Azure Paired regions.

辅助链接缓存如何进行故障转移?How does failing over to the secondary linked cache work?

异地复制的缓存不支持跨 Azure 区域的自动故障转移。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. Redis 的主要优势之一是,它是一个延迟极低的存储。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. 然后将 Redis 客户端更改为使用(以前链接的)辅助缓存的连接终结点。Then, change your Redis client to use the connection endpoint of the (formerly linked) secondary cache. 取消链接两个缓存后,辅助缓存将再次成为常规的读取写入缓存,并直接从 Redis 客户端接受请求。When the two caches are unlinked, the secondary cache becomes a regular read-write cache again and accepts requests directly from Redis clients.

后续步骤Next steps

了解有关 Azure Cache for Redis 功能的详细信息。Learn more about Azure Cache for Redis features.