聚焦 SQL 数据库活动异地复制

 Tobias Ternstrom  US-DS-PM 首席部门项目经理

本文作为一系列业务连续性和灾难恢复文章的开篇，概述了业务连续性的各种场景，然后重点介绍 SQL 数据库高级服务级别提供的活动异地复制的用法。有关活动异地复制的详细信息，请观看生动而详实的Channel 9视频。在该视频中，Sasha Nosov 和 Scott Klein 将探讨活动异地复制的工作原理，以及如何使用它来解决实际的业务问题。

什么是业务连续性？

业务连续性是指可以帮助企业在发生系统中断（尤其是计算基础结构发生中断）时保持持续运营的机制、策略和过程。

从数据库角度来看，可能存在四种主要的中断场景：

1. 影响数据库节点的本地硬件或软件发生故障，例如，磁盘驱动器发生故障。
2. 数据损坏或删除 – 通常是由于应用程序缺陷或人为错误造成的。这种故障本身与特定应用程序有关，一般无法由基础结构自动检测或解决。
3. 数据中心中断，可能是由自然灾害造成的。这种场景要求具备一定程度的地域冗余，可以将应用程序故障转移到备用数据中心。
4. 升级或维护错误 – 在按计划对应用程序或数据库进行升级或维护期间发生的意外问题，可能需要快速回滚到原先的数据库状态。

Azure SQL 数据库如何启用业务连续性？

Azure SQL 数据库会自上而下构建为一种稳定可靠的高可用性数据库服务，它采用这样一种机制，即始终为每个数据库保留三个或三个以上的副本，并会在响应前至少对两个副本进行更新。这种高可用性(HA)系统解决了第一种场景的问题，即本地硬件和软件故障。

当前的新服务级别（基本、标准和高级级别）提供了一些功能，以解决上述其余三种场景的问题，从而使业务连续性迈上了一个新台阶：

数据损坏或删除。基本、标准和高级级别数据库支持自助式时间点还原功能，可以将数据库还原为早先的状态。这样，就可以防止因应用程序或用户错误而导致数据损坏或被删除。每周会进行一次完整备份，每天会进行一次差异备份，每 5 分钟会进行一次事务日志备份。对于基本级别数据库，备份会保留 7 天，对于标准级别数据库，备份会保留 14 天，对于高级级别数据库，备份会保留 35 天。您可以在保留期内将数据库（包括最近删除的数据库）还原到任意时间点。

数据中心中断。此外，还会保护基本、标准和高级数据库服务级别不出现长时间数据中心中断，因为这可能需要将数据库恢复到其他区域的其他数据中心内。我们为此提供了三种地域冗余解决方案：

• 地域还原（适用于基本，标准和高级级别），可用于恢复到上次每日备份的地域冗余副本。
• 标准异地复制（适用于标准和高级级别数据库），可用于扩展本地 HA 系统，以便在配对区域创建和维护另一个辅助数据库。这些辅助数据库处于脱机和不可访问状态，除非发生数据中心中断，此时，它们将被置于联机状态，以使应用程序可以故障转移到其中。
• 活动异地复制（适用于高级级别数据库），可提供最丰富的解决方案，数据丢失风险最低，恢复时间最短。它可将标准异地复制扩展为多达 4 个异地复制的辅助数据库，这些数据库会始终保持联机和可读状态，同时，也可用于平衡负载，或者在从全球任何地点访问复制的数据时可以保证延迟较低。

升级或维护错误。 通过活动异地复制，您可以为数据库创建一份连续复制的副本，在对该数据库或应用程序进行更新或维护之前，可以立即冻结该数据库。如果在该过程期间或之后检测到任何错误，则可以轻松快捷地将该数据库回滚至该副本。

不同的服务级别可使用不同的解决方案，但是请记住，您可以轻松地在各个服务级别之间升级或降级数据库。例如，您可能选择在进行重要升级之前先将标准级数据库升级为高级，并使用活动异地复制。升级完成后，可以将该数据库重新降级，以降低成本。

活动异地复制详细信息

至此，我们已经了解了在业务连续性环境下，何时可以使用活动异地复制。现在，让我们深入探讨一下活动异地复制的工作原理以及使用方式。

图 1. 高级数据库在相同或不同区域中最多可以拥有 4 个可读辅助数据库。

活动异地复制关系可以通过 Azure 管理门户、PowerShell 或 REST API 来创建和管理。在该门户中，您可以从主数据库或辅助数据库管理复制关系。您可以从主数据库监视每个辅助数据库的复制状态。

图 2. 使用 Azure 管理门户创建和监视多达四个地域辅助数据库的状态。

可以创建多达四个可读辅助数据库，每个辅助数据库都与主数据库同名，但位于不同的服务器上。辅助数据库在首次创建后会使用主数据库的当前状态来初始化。每个辅助数据库在初始化完成后，即会成为主数据库的一个连续副本。与所有其他数据库一样，辅助数据库也会通过常规 HA 系统在本地进行保护。

与本地 HA 复制模式不同的是，从主数据库异地复制到辅助数据库是异步的。对主数据库应用的事务会复制并应用到辅助数据库，而在等待该操作期间，主数据库仍可继续处理事务。所做的更改会被缓存下来，确保复制系统在复制到远程位置期间发生临时连接问题或长时间延迟时能够恢复。

为了确保对辅助数据库应用的事务不会对主数据库构成瓶颈，辅助数据库必须具有与主数据库相同或更高的性能级别。

辅助数据库是可读的，因此，可以支持独立的只读工作负荷。可以通过该功能在多个数据库之间平衡复杂的查询工作负荷，或者在全球其他地点提供较短的应用程序数据访问延迟。

图 3.如果数据中心中断影响到主数据库，可以终止复制关系，并将应用程序故障转移到辅助数据库。

可以手动管理复制关系，以便可以随时终止该关系。如果从主数据库终止复制关系，您可以选择是立即终止并丢失任何待处理的事务还是在应用所有待处理的事务后再终止。

如果发生数据中心中断并影响到主数据库，仍然可以手动执行故障转移，这样，您就可以完全控制是否执行该操作以及何时执行。如果主数据库不可用，可以从辅助数据库终止该关系。从数据库始终会立即终止该关系，并丢失主数据库变为不可用时尚未复制的任何事务。可能丢失多少数据取决于主数据库发生故障时的活动状态，以及是否在连接期间缓存了事务。是否要决定终止复制关系，应综合考虑可能的数据丢失问题以及是否希望重新恢复应用程序。

一旦终止了与辅助数据库的关系，该数据库就会成为一个普通的读写数据库。此时，您可以将对该数据库具有完全访问权限的应用程序进行故障转移。由于每个辅助数据库都是一个独立的数据库，并与主数据库同名，但位于不同的服务器上，因此，您需要使用更新后的连接字符串重新配置应用程序。

在处理完故障转移过程后，您可能希望仅使用新的生产数据库作为主数据库来重新构建与以前使用的异地复制关系相同的异地复制关系模式。这样就可以确保您获得应用程序和业务连续性策略所需的地域冗余和负载平衡功能。

图 4. 终止最初与辅助数据库建立的关系后，应创建新的异地复制关系，以保护新的主数据库并满足任何负载平衡需求。

活动异地复制可以整合到各种应用程序体系结构模式中，这些模式会采用不同的假设，例如，哪些层和组件风险最高，以及哪些组件可能分布在不同的地理区域。有关该主题的详细信息，请参见此文章。

总结

活动异地复制不仅提供了强大的地域冗余功能以保护数据库不受数据中心中断的影响，而且还支持其他业务连续性场景。对于高级级别数据库，目前已提供了活动异地复制功能。

请阅读有关 SQL 数据库中业务连续性（包括活动异地复制）的更多信息，或者花几分钟时间观看 Sasha 和 Scott 在Channel 9 上针对活动异地复制如何为业务提供保护展开的讨论。

本文翻译自：https://azure.microsoft.com/blog/2014/07/12/spotlight-on-sql-database-active-geo-replication/