通过

活动异地复制

适用于：Azure SQL 数据库

本文概述了 Azure SQL 数据库的活动异地复制功能，使你能够连续将数据从主数据库复制到可读的辅助数据库。 可读辅助数据库可能位于与主数据库相同的 Azure 区域中，或者，更常见的是，位于不同的区域。 这种可读辅助数据库也称为异地辅助数据库或异地副本。

活动异地复制按数据库进行配置。 若要故障转移一组数据库，或者如果应用程序需要稳定的连接终结点，请考虑改用故障转移组。

还可以 迁移具有活动异地复制的 SQL 数据库。

概述

活动异地复制旨在充当业务连续性解决方案。 活动异地复制可让你在发生区域性灾难或大规模中断时执行各个数据库的快速灾难恢复。 设置异地复制后，就可以向不同 Azure 区域的异地辅助数据库发起异地故障转移。 异地故障转移由应用程序以编程方式启动或由用户手动启动。

下图演示了使用活动异地复制的异地冗余云应用程序的典型配置。

活动异地复制示意图。

如果主数据库发生故障，则可以启动到任何辅助数据库的异地故障转移。 当辅助数据库提升为主角色时，所有其他辅助数据库会自动链接到新的主数据库。

可以使用以下任何方法来管理异地复制并启动异地故障转移：

活动异地复制使用 AlwaysOn 可用性组 技术将主副本上生成的事务日志异步复制到所有异地副本。 尽管在任意给定时间，辅助数据库可能略微滞后于主数据库，但系统可以保证辅助数据库上的数据在事务上是一致的。 换句话说，未提交事务所做的更改将不可见。

注意

活动异地复制会通过将数据库事务日志从主要副本流式传输到次要副本来复制更改。 它与 事务复制无关，它通过在订阅服务器上执行 DML（INSERT、UPDATE、DELETE）命令来复制更改。

异地复制提供区域冗余。 区域冗余使应用程序能够在自然灾害、灾难性人为失误或恶意行为导致整个 Azure 区域或部分区域永久性丢失后得以快速恢复。 可以在 Azure SQL 数据库的业务连续性概述中找到异地复制 RPO。

下图显示了配置的活动异地复制示例，其中主数据库位于美国西部 2 区域，异地辅助数据库位于美国东部区域。

Azure 门户的屏幕截图，其中显示了 SQL DB 异地复制关系。

除了灾难恢复外，活动异地复制还可用于以下情况：

  • 数据库迁移：可以使用活动异地复制将数据库从一台服务器迁移到另一台服务器，只需要极少的停机时间。
  • 应用程序升级：可以在应用程序升级期间创建额外的辅助数据库作为故障回复副本。

为了实现完整的业务连续性，添加数据库区域冗余只是解决方案的一部分。 在发生灾难性故障后，端对端地恢复应用程序（服务）需要恢复构成该服务的所有组件以及所有依赖服务。 这些组件的示例包括客户端软件（例如，使用自定义 JavaScript 的浏览器）、Web 前端、存储和 DNS。 所有组件必须能够弹性应对相同的故障，并在应用程序的恢复时间目标 (RTO) 值内变为可用，这一点非常关键。 因此，需要识别所有依赖服务，并了解它们提供的保证和功能。 然后，必须执行适当的步骤来确保对用户的服务所依赖的服务执行故障转移期间，用户的服务能够正常运行。 有关设计灾难恢复解决方案的详细信息，请参阅 使用 Azure SQL 数据库设计全球可用服务。

术语和功能

  • 自动异步复制

    只能为现有数据库创建异地辅助数据库。 可以在除具有主数据库的服务器以外的任何逻辑服务器上创建异地辅助数据库。 创建后，将用主数据库的数据填充异地次要副本。 这个过程称为种子设定。 创建异地辅助数据库并设定其种子后，会自动以异步方式将主数据库的更新复制到异地次要副本。 异步复制是指先在主数据库上提交事务，然后再复制事务。

  • 可读异地次要副本

    应用程序可使用与访问主数据库时所用的相同或不同的安全主体来访问异地次要副本以执行只读查询。 有关详细信息，请参阅 使用只读副本卸载只读查询工作负荷。

    重要

    你可以使用异地复制在与主要副本相同的区域中创建次要副本。 你可以使用这些次要副本来满足同一区域的读取扩展方案。 但是，同一区域中的次要副本不能针对灾难性故障或大规模中断提供额外的复原能力，因此不是用于灾难恢复目的的适当故障转移目标。 它也不保证可用性区域隔离。 使用业务关键或高级服务层级 区域冗余配置 或常规用途服务层级 区域冗余配置 来实现可用性区域隔离。

  • 故障转移（无数据丢失）

    故障转移在完成完整数据同步之后切换主数据库和异地辅助数据库的角色，因此不会丢失数据。 故障转移的持续时间取决于主数据库上需要同步到异地辅助数据库的事务日志的大小。 故障转移适用于以下方案：

    • 不可接受数据丢失时在生产环境中执行 DR 演练
    • 将数据库重新定位到不同的区域
    • 缓解服务中断（称为故障回复）后将数据库恢复到主要区域。

  • 强制故障转移（可能导致数据丢失）

    强制故障转移或强制异地故障转移立即将辅助角色切换为主要角色，而无需等待与主要节点进行同步。 在主数据库上提交但尚未复制到辅助数据库的任何事务都将丢失。 当无法访问主数据库时，此操作设计为服务中断期间的恢复方法，但必须快速还原数据库的可用性。 当原始主数据库重新联机时，它将自动重新连接，使用主数据库中的当前数据重新设定种子，并成为新的异地辅助数据库。

    重要

    在故障转移或强制故障转移之后，新主数据库的连接终结点将发生更改，因为新主数据库现在位于不同的逻辑服务器上。

  • 多个可读的异地辅助数据库

    最多可为一个主数据库创建四个异地辅助数据库。 如果只有一个辅助数据库，一旦它发生故障，应用程序就会遭受更高的风险，直到创建了新的辅助数据库。 如果存在多个辅助数据库，即使其中一个辅助数据库发生故障，应用程序仍会受到保护。 也可使用其他辅助数据库来横向扩展只读工作负荷。

    提示

    如果使用活动异地复制生成全球分布的应用程序，并需要在四个以上的区域中提供数据只读访问，则可以创建辅助数据库的辅助数据库（此过程称为链接）来创建其他异地副本。 链式异地副本上的复制延迟可能高于直接连接到主数据库的异地副本。 仅支持以编程方式设置链式异地复制拓扑，而不支持从 Azure 门户进行设置。

  • 弹性池中数据库的异地复制

    每个异地辅助数据库可以是单一数据库，也可以是弹性池中的数据库。 每个异地辅助数据库的弹性池选项是独立的，并且不依赖于拓扑中任何其他副本的配置（主要副本或次要副本）。 每个弹性池都包含在单个逻辑服务器中。 因为逻辑服务器上的数据库名称必须是唯一的，所以同一主数据库的多个异地辅助数据库永远不会共享弹性池。

  • 用户控制的异地故障转移和故障回复

    已经完成初始种子设定的异地辅助可以在任何时候由应用程序或用户显式切换到主要角色（故障转移）。 在无法访问主节点的中断期间，只能使用强制故障转移，这会立即将异地辅助数据库提升为新的主数据库。 缓解故障后，系统会自动将恢复的主数据库设置为异地辅助数据库，并使其与新的主数据库同步更新。 由于异地复制的异步特性，如果主数据库在将最新的事务复制到异地辅助数据库之前发生故障，那么在强制故障转移期间，这些事务可能会丢失。 当具有多个异地辅助数据库的主数据库进行故障转移时，系统会自动重新配置复制关系，并将剩余的异地辅助数据库链接到新升级的主数据库，无需任何用户干预。 导致异地故障转移的服务中断得到缓解后，可能需要将主数据库还原到其原始区域。 执行手动故障转移。

  • 备用副本

    如果辅助副本 仅用于 灾难恢复（DR），并且没有任何读取或写入工作负荷，则可以将副本指定为 备用 副本，以节省许可成本。

准备进行异地故障转移

若要确保应用程序在异地故障转移后可以立即访问新的主服务器，请验证辅助服务器的身份验证和网络访问是否正确配置。 有关详细信息，请参阅 配置和管理用于异地还原或故障转移的 Azure SQL 数据库安全性。 还要验证辅助数据库上的备份保留策略与主数据库的备份保留策略是否匹配。 此设置不是数据库的一部分，并且不是从主数据库中复制的。 默认情况下，异地辅助数据库配置的默认 PITR 保留期为七天。 有关详细信息，请参阅 Azure SQL 数据库中的自动备份。

重要

如果数据库是故障转移组的成员，则无法使用异地复制故障转移命令启动其故障转移。 对该组使用故障转移命令。 如果需要故障转移单个数据库，则必须先将其从故障转移组中删除。 有关详细信息，请参阅故障转移组。

配置异地辅助数据库

主数据库和异地辅助数据库都需要有相同的服务层级。 此外，强烈建议将异地辅助数据库配置为与主数据库相同的备份存储冗余、 计算层 （预配或无服务器）和计算大小（DTU 或 vCore）。 如果主数据库遇到大量写入工作负荷，则计算大小较小的异地辅助数据库可能无法保持同步。 这会导致异地辅助数据库上的复制延迟，并可能最终导致异地辅助数据库不可用。 为了降低这些风险，活动异地复制可在必要时降低（限制）主数据库的事务日志率，以允许其辅助数据库保持同步。

不均衡异地辅助数据库配置的另一个结果是，在故障转移后，应用程序性能可能会因为新的主数据库的计算能力不足而降低。 在这种情况下，有必要纵向扩展数据库，使其有足够的资源，这可能需要很长时间，并且需要在纵向扩展过程结束时进行 高可用性 故障转移，这可能会中断应用程序工作负荷。

如果决定使用其他配置创建异地辅助数据库，则应在主数据库上监视随时间变化的日志 IO 速率。 这使你可以估计维护复制负载所需的异地辅助数据库的最小计算大小。 例如，如果主数据库是 P6 (1000 DTU)，其日志 IO 维持在 50%，则异地辅助数据库需要至少为 P4 (500 DTU)。 若要检索历史日志 IO 数据，请使用 sys.resource_stats 视图。 若要检索具有更高粒度的最新日志 IO 数据，以便更好地反映短期峰值，请使用 sys.dm_db_resource_stats 视图。

提示

以下情况下可能发生事务日志 IO 限制：

  • 如果异地辅助数据库的计算大小低于主数据库。 在 sys.dm_exec_requests 和 sys.dm_os_wait_stats 数据库视图中查找 HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO 等待类型。
  • 与计算大小无关的原因。 有关详细信息，包括不同类型日志 IO 节流的等待类型，请参阅 事务日志速率管理。

默认情况下，异地辅助数据库的备份存储冗余与主数据库的备份存储冗余相同。 可以选择使用不同的备份存储冗余配置异地辅助数据库。 备份始终在主数据库上执行。 如果使用不同的备份存储冗余配置辅助数据库，则在异地故障转移后，当异地辅助数据库升级到主数据库时，将根据新的主数据库（上一个辅助数据库）上选择的存储类型（RA-GRS、ZRS、LRS）对新备份进行存储和计费。

使用备用副本节省成本

如果次要副本 仅用于 灾难恢复（DR），并且没有任何读取或写入工作负载，那么您可以在配置新的活动异地复制关系时，通过将数据库指定为备用来节省许可成本。

查看 无许可证备用副本 以了解详细信息。

跨订阅异地复制

  • 只要两个订阅位于同一 Microsoft Entra 租户中，就可以使用 Azure 门户设置跨订阅的活动异地复制。

  • 如果在主逻辑服务器或辅助逻辑服务器上启用了仅限 Microsoft Entra 的身份验证，并且尝试使用 Microsoft Entra ID 用户进行创建，则不支持在相同或不同 Microsoft Entra 租户的逻辑服务器上创建跨订阅的异地辅助数据库。

有关方法和分步说明，请参阅教程：配置活动异地复制和故障转移（Azure SQL 数据库）。

专用终结点

通过专用终结点连接到主服务器时，不支持使用 T-SQL 添加异地辅助数据库。

  • 如果配置了专用终结点但允许公共网络访问，则在从公共 IP 地址连接到主服务器时支持添加异地辅助数据库。
  • 添加异地辅助数据库后，可以拒绝公用网络访问。

保持凭据和防火墙规则同步

使用公用网络访问连接到数据库时，建议对异地复制的数据库使用 数据库级 IP 防火墙规则 。 这些规则与数据库一起复制，从而确保所有异地辅助数据库具有与主数据库相同的 IP 防火墙规则。 此方法不再需要客户手动配置和维护承载主数据库和辅助数据库的服务器上的防火墙规则。 同样，使用 包含的数据库用户 进行数据访问可确保主数据库和辅助数据库始终具有相同的身份验证凭据。 这样，在异地故障转移后，不会因身份验证凭据不匹配而造成中断。 如果使用的是登录名和用户（而不是包含的用户），你必须采取额外的步骤来确保辅助数据库中存在相同的登录名。 有关配置详细信息，请参阅 配置和管理用于异地还原或故障转移的 Azure SQL 数据库安全性。

缩放主数据库

无需断开任何异地辅助数据库，即可将主数据库纵向扩展或纵向缩减到不同的计算大小（在相同服务层级中）。 在纵向扩展时，建议你首先扩展异地辅助数据库，然后再扩展主数据库。 纵向缩减时，则按相反顺序进行：先缩减主数据库，再缩减辅助数据库。

有关故障转移组的信息，请查看在故障转移组中缩放副本。

防止关键数据丢失

由于广域网的延迟时间较长，异地复制使用了异步复制机制。 如果主数据库发生故障，异步复制会导致数据丢失不可避免。 为了防止关键事务丢失，应用程序开发人员可以在提交事务后立即调用 sp_wait_for_database_copy_sync 存储过程。 调用 sp_wait_for_database_copy_sync 会阻止调用线程，直到最后提交的事务已传输并强制执行到辅助数据库的事务日志中。 它还会等待传输的事务在辅助数据库上进行重播（重做）。 sp_wait_for_database_copy_sync 范围限定为特定异地复制链接。 对主数据库具有连接权限的任何用户都可以调用此过程。

注意

sp_wait_for_database_copy_sync 防止特定事务异地故障转移后数据丢失，但不保证完全同步进行读取访问。 sp_wait_for_database_copy_sync 过程调用导致的延迟可能很明显，具体取决于调用时主数据库上尚未传输的事务日志大小。

监视异地复制延迟

若要监视 RPO 的滞后时间，请使用主数据库上 sys.dm_geo_replication_link_status 的 replication_lag_sec 列。 它显示主数据库上提交的事务与强制执行到辅助数据库上的事务日志的事务之间的延迟时间（以秒为单位）。 例如，如果延迟为一秒，则表示如果主数据库此时受到中断的影响，并且启动了异地故障转移，则在上一秒提交的事务将丢失。

若要根据已对异地辅助数据库强制执行的主数据库更改来度量延迟，请将异地辅助数据库上的 last_commit 时间与主数据库上的相同值进行比较。

提示

如果主数据库上的 replication_lag_sec 为 NULL，则表示主数据库当前不知道异地辅助数据库的滞后情况。 这通常发生在进程重启之后，应该是一个暂时情况。 如果 replication_lag_sec 长时间返回 NULL，请考虑发送警报。 这可能表示由于连接失败，异地辅助数据库无法与主数据库进行通信。

还可能会导致异地辅助数据库和主数据库上 last_commit 时间之间的差值变大。 例如，如果在较长一段时间没有更改后在主数据库上进行提交，那么在快速归零之前，该差值将上升到一个很大的值。 如果这两个值之间的差值长时间保持较大，请考虑发送警报。

以编程方式管理活动异地复制

也可以使用 T-SQL、Azure PowerShell 和 REST API 以编程方式管理活动异地复制。 下表描述了可用的命令集。 活动异地复制包括一组用于管理的 Azure 资源管理器 API，包括 Azure SQL 数据库 REST API 和 Azure PowerShell cmdlet。 这些 API 支持 Azure 基于角色的访问控制 (Azure RBAC)。 有关如何实现访问角色的详细信息，请参阅 Azure 基于角色的访问控制（Azure RBAC）。

重要

这些 T-SQL 命令仅适用于活动异地复制，不适用于故障转移组。

命令 说明
ALTER DATABASE 使用 ADD SECONDARY ON SERVER 参数为现有数据库创建辅助数据库，并开始数据复制
ALTER DATABASE 使用 FAILOVER 或 FORCE_FAILOVER_ALLOW_DATA_LOSS 将辅助数据库切换为主数据库，以启动故障转移
更改数据库 使用 REMOVE SECONDARY ON SERVER 终止 SQL 数据库和指定的辅助数据库之间的数据复制。
sys.geo_replication_links 返回有关服务器上每个数据库的所有现有复制链接的信息。
sys.dm_geo_replication_link_status 获取有关给定数据库的复制链接的上次复制时间、上次复制滞后时间和其他信息。
sys.dm_operation_status 显示所有数据库操作的状态，包括对复制链接的更改。
sys.sp_wait_for_database_copy_sync 使应用程序等待，直到所有提交的事务都被强制执行到异地辅助数据库的事务日志中。

相关内容

配置活动异地复制：

其他业务连续性内容：