Azure SQL Database 标准地域复制

  原文地址：https://azure.microsoft.com/blog/2014/09/03/azure-sql-database-standard-geo-replication/

Tony Petrossian

Azure SQL Database产品项目经理

在本文中，我们将继续讨论业务连续性场景，并介绍新推出的Azure SQL Database标准地域复制功能。标准地域复制允许您配置数据将提交的事务从主数据库异步复制到预定义Azure 区域的辅助数据库。在深入介绍详细信息之前，总结一下预览版本中目前提供的各种业务连续性功能十分有用，我们将在2014 年发布的新服务层上下文中进行讨论。您可以在这篇文章中了解有关服务层具体特征的详细信息。

业务连续性模型

在上一篇关于活动地域复制的文章中，Tobias已经对业务连续性挑战进行了定义。为了快速复习一下，我们需要熟悉几个概念，以便充分理解本文的内容：

• 灾难恢复 (DR)：恢复应用程序正常业务功能的过程
• 时间点还原：用于将数据库还原至过去的某个时间点（在备份保留期限内），以便从人为错误或编程错误导致的数据损坏中恢复
• 恢复时间目标 (RTO)：应用程序发生故障后到完全恢复之前经历的最长停机时间
• 恢复点目标 (RPO)：应用程序发生故障后到完全恢复之前可能丢失的最近数据更改的最大量（时间间隔）

下表显示了不同服务层的数据连续性功能的区别：

定义业务连续性/灾难恢复 (BCDR)模型的主要因素在于，应用程序的性能概况有助于确定哪种业务连续性解决方案满足需求。如果您的应用程序以较低的更新率处理较少量数据，并且基本层可以提供适当的性能级别，那么地域还原应该满足其恢复需求。如果您的应用程序处理较大量数据，并且需要性能级别更高的标准层和更具竞争力的RPO，那么标准地域复制很可能是适当的灾难恢复解决方案。活动地域复制专为处理超大量更新的应用程序而设计，需要以最低的RPO执行最先进的恢复技术。这样，随着您从基本层扩展到高级层，SQL Database BCDR模型就能提供更强大的业务连续性功能。由于用来读取的数据处理的RPO需求可能较低，每个较高的服务层还包括较低服务层中提供的BCDR功能。

标准地域复制与活动地域复制的区别

下面我们来仔细分析一下用户体验，看看标准地域复制与活动地域复制之间存在怎样的区别。

首先，标准地域复制与活动地域复制构建于相同的技术基础之上，但已针对写入密度较低的应用程序进行了优化。在定义该功能的过程中，需要考虑以下关键注意事项：(a)发现更新率与高级别灾难恢复SLA不符的应用程序；(b)这些应用程序只需执行简单恢复工作流，无需使用复杂监控逻辑来做出故障转移决策；(c)这些应用程序通常对于成本较为敏感。为实现这些预期，我们进行了以下简化：

1. 在微软定义的“DR配对”Azure区域创建了一个辅助数据库。您可以在此处找到DR对列表。

2. 辅助数据库在主数据库中可见，但在完成故障转移前无法直接连接（脱机辅助数据库）。

3. 辅助数据库可享受折扣价格，因为该数据库不可读（脱机）。

4. 如果托管主数据库的数据中心长期停机，该服务将启用故障转移功能。从发生故障到声明可能需要用时 1 小时。该门户会将受影响的服务器显示为“已降级”。

5. 在发生停机的情况下，如果该应用程序或客户未启动故障转移，并且主位置在故障发生后 24 小时内未恢复，带有标准地域复制功能的所有数据库将自动故障转移到备用位置。

图 1 展示了标准地域复制的典型配置：

图 1. 数据库可在 DR 配对区域中包含一个脱机辅助数据库。

大家可以看到，标准地域复制的焦点是启用灾难恢复，恢复某一地区Azure SQL Database服务的大规模停机状况。为此，只需使用更强大的活动地域复制的部分功能。但是，在某些场景下，也可以使用标准地域复制来支持无法通过后者支持的情况。下表对该增量进行了总结：

为什么在高级数据库中使用标准地域复制替换活动地域复制？

用户可通过标准地域复制、活动地域复制或同时启用两者来保护高级数据库。那么，何时选择使用标准地域复制，而不是更强大的活动地域复制呢？标准地域复制一直作为较为简便而廉价的 DR 解决方案，尤其适用于更新率较低的应用程序。如果高级数据库主要用于处理大容量读取工作负载，那么标准地域复制可能是一个不错的选择。在标准地域复制中，您将无法选择辅助数据库位置、无法获得多达四个辅助数据库的读取访问权限，也无法全面掌控故障转移的时机和位置。作为回报，使用标准地域复制时，您将会获得由微软负责托管的简化监控和故障转移工作流。但是，您不必为做出选择而烦恼，您可以在高级数据库中选择使用标准地域复制创建脱机辅助数据库来实现故障转移，然后再创建一个或多个可读辅助数据库提供针对密集读取工作负载的负载平衡支持。

数据库故障转移

标准地域复制专门用于提供数据层中断 DR 解决方案。除非托管主数据库的区域发生Azure SQL Database服务中断，否则将无法启动向配对区域的辅助数据库故障转移。由于应用程序层中断，标准地域复制不支持手动故障转移数据库。活动地域复制可提供该场景所需的故障转移和位置控制。

如果某一区域发生长时间停机，微软将通过标准地域复制对所有受保护的数据库启用故障转移。其目标在于，该服务将确定是否需要在发生故障后一小时内进行故障转移。一旦启用，您将可以通过终止辅助数据库的地域复制关系来发起实际故障转移。该方法可简化故障转移逻辑。应用程序只需等待显示故障转移启用标志，而后确定执行故障转移还是等待数据中心进行恢复。如果您的应用程序需要优化，以便提高可用性并可忍受长达 1 小时的数据损失，那么只要通过服务启用即可进行故障转移。如果您的应用程序对数据丢失较为敏感，可以选择等待SQL Database服务进行恢复。这样一来，就不会丢失任何数据。但是，如果主数据中心（和数据库）未能在 24 小时内恢复，该服务将自动启动故障转移。在这种情况下，应用程序将发生数据丢失并会造成 24 小时停机。在任何情况下，无论是对数据库执行故障转移还是等待自动操作，都必须对您的应用程序进行适当的重新配置才能连接到故障转移的数据库。

完成故障转移后，您势必希望确保新的主数据库同样受到保护。作为启用服务故障转移流程的一部分，该服务将更新其DR配对配置以使用备用区域。这样，您就可以从新的主数据库启动地域复制以提供保护。由于植入新的辅助数据库将需要一些时间（可能需要几小时，具体取决于数据库大小），您需要确定是否要在植入期间恢复可用性，并且需要承担不加防护操作应用程序的风险。最明智的方法是等待新的辅助数据库为故障转移的数据库提供保护，然后再激活应用程序。完成植入后，DR 配置可能会与图 2 所示的场景类似。

图 2. 使用更新后的 DR 配对执行故障转移后，应用程序可以创建新的辅助数据库。

故障转移演练

由于数据库故障转移与数据密切相关并且是破坏性的过程，应定期测试故障转移工作流，以便确保应用程序准备就绪。这个过程称为 DR 演练。除了作为一项有用的工程实践以外，大部分行业安全标准还要求将其作为合规认证的一部分。虽然正常情况下不会启用从脱机辅助数据库进行故障转移，但仍然可以通过停止主数据库地域复制来测试整体 DR 工作流。请注意，如果终止时主数据库处于活动状态，那么提交至主数据库但尚未复制到辅助数据库的所有事务都将丢失。终止后，辅助数据库将可供全面访问，应用程序可将它作为新的主数据库。因为可能造成数据丢失，演练期间将不会对主数据库实施保护，我们建议客户不要在生产数据库上开展 DR 演练。相反，我们建议在同一区域创建一个数据库测试副本，并为该副本创建一个脱机辅助数据库，然后在测试上下文中使用该副本及其辅助数据库来验证应用程序的故障转移工作流。

管理工具

标准地域复制只提供活动地域复制的部分REST API。若要管理标准地域复制，可以使用PowerShell cmdlet或 Azure管理门户提供的此 API。由于此功能还处于预览阶段，您需要首先注册Azure SQL Database新服务层预览版。启用标准地域复制的最简便方法是使用Azure管理门户的 GEO-REPLICATION 选项卡，如图 3 所示。

图 3. 使用 Azure 管理门户创建并监控脱机地域复制状态。

需要注意的是，您可以随时退出地域复制。共有两种退出方法。您可以在主数据库上终止地域复制关系，也可以简单丢弃辅助数据库。第一种方法对于取消误启用操作最有效。如果在辅助数据库植入完成之前发出通知，将不会对辅助数据库收费。如果之后才发出，将必须单独删除过去的辅助数据库，按日常费用比例支付额外数据库的费用。第二种方法只需一步即可自动终止地域复制，丢弃辅助数据库并停止相关计费。

小结

标准地域复制将为您提供强大的灾难恢复解决方案（采用适当更新率的应用程序）。它不如活动地域复制那样灵活，但我们相信它可以满足一大类应用程序的需求。请告知我们您的想法！我们将仔细聆听您的反馈意见。注册新服务层预览版，试用标准地域复制。您可以在这篇文章中阅读更多相关内容。