本文档介绍 Microsoft SQL Server 的灾难恢复 (DR) 策略，适合通过 Google Cloud 设计和实施灾难恢复的架构师和技术主管阅读学习。
数据库可能会由于各种原因而变得不可用，例如硬件或网络故障。为了在故障期间提供不间断的数据库访问，您需要维护一个辅助数据库，该辅助数据库是主数据库的副本。将辅助数据库放在与主数据库不同的位置，能够有效提高主数据库故障期间辅助数据库可用的可能性。
如果主数据库不可用，您的关键任务应用将连接到辅助数据库，从其中最近已知的一致数据状态继续为您的用户提供服务，尽可能地缩短停机时间，甚至无需停机。
在主数据库发生故障时启用辅助数据库的过程称为数据库灾难恢复 (DR)。辅助数据库能够在主数据库不可用时恢复数据库服务。 理想情况下，辅助数据库在主数据库不可用时具有与其完全相同的一致状态，或者仅丢失主数据库最近的事务中极小的一部分。
数据库灾难恢复对企业客户来说是必不可少的功能。主要原因在于关键任务应用需要具备业务连续性。例如，关键任务应用可产生收入（电子商务）、提供持续可靠的服务（飞机或动力装置管理），或为生命保护功能提供支持（患者监控）。在所有这些示例中，应用的持续可用性至关重要，因为这些应用被视为关键任务。
包括 Microsoft SQL Server 在内的大多数数据库管理系统都提供灾难恢复功能。本架构文档介绍如何在 Google Cloud 环境中实现 SQL Server 提供的灾难恢复功能。
术语
以下部分介绍了本文档中使用的术语。
通用 DR 架构
下图展示了通用灾难恢复架构拓扑。
在上图中，应用访问主数据库，而辅助数据库处于备用状态，并建立主数据库状态的镜像。客户端访问 Google Cloud 上运行的应用。
如果主数据库不可用，则数据库管理员或运营团队必须决定启动灾难恢复过程。如果启动了数据库灾难恢复，则应用将重新连接到辅助数据库。成功连接后，该应用可以再次为其客户提供服务。在理想情况下，应用能够以最快的速度访问辅助数据库，因此客户甚至可能不会遇到中断。另一种方法是等待主数据库再次可供访问，而不启动灾难恢复。 例如，如果灾难是间歇性的，则采用这种方法而不进行故障切换可能会更快解决问题。
主数据库和辅助数据库
主数据库供一个或多个应用访问，以便为应用的状态管理提供持久性服务。辅助数据库与主数据库相关联，它包含主数据库的副本。理想情况下，辅助数据库的内容在任何时间点都与主数据库的内容完全一致。但在许多情况下，由于在主数据库上应用事务性更改存在延迟，辅助数据库上的内容会滞后于主数据库。您可以为主数据库关联多个辅助数据库，具体取决于该数据库是否支持相关技术。SQL Server 支持为主数据库关联多个辅助数据库。
灾难恢复
如果主数据库不可用，则 DR 会将辅助数据库用作主数据库。如果存在多个辅助数据库，您可以手动选择其中一个数据库，或由系统根据首选的故障切换列表进行选择。应用必须重新连接到新的主数据库才能继续访问其状态。如果新的主数据库与先前主数据库的最后已知状态不同步，则应用从过去状态（也称为“闪回”）开始运行。
请务必确保每个主数据库至少有一个辅助数据库始终在运行。执行一次灾难恢复后，请确保设置新的辅助数据库以应对将来的灾难恢复场景。
故障切换、切换和回退
在以下几种场景下，主数据库和辅助数据库之间的角色会发生更改：
- 故障切换：将辅助数据库用作新的主数据库并将所有应用连接到该数据库的过程。故障切换不是故意执行的，其触发原因在于主数据库变得不可用。您可以将故障切换配置为自动或手动触发。
- 切换：与故障切换相反，从主数据库切换到辅助数据库（新的主数据库）是故意触发的，目的是进行初始测试和计划性维护。通过定期切换来测试 DR 系统，能够确保灾难恢复的持续可靠性。
- 回退：回退是指主数据库修复之后，逆转新的主数据库成为辅助数据库的过程。回退是故意触发的，目的是在启动故障切换或切换之前重新建立状态。此操作不是必需的，但可以根据具体的灾难恢复要求来执行，例如地点或可用资源。
Google Cloud 地区和区域
数据库等资源位于 Google Cloud 地区和区域中，每个地区属于一个区域。地区是一个单点故障网域。 我们建议在一个区域内的多个地区中部署高可用性容错资源。
为了防止整个区域发生中断，您可以为灾难恢复建立多区域策略。例如，主数据库位于一个区域中，其对应的辅助数据库位于另一个区域中。
活跃模式：“活跃-非活跃”和“活跃-活跃”
主数据库是用于执行读写操作（DML 操作）的数据库，应用可以访问主数据库以管理其状态。主数据库称为“活跃”数据库。相应的辅助数据库是非活跃的，因为它复制主数据库的内容，但无法供任何应用执行更改状态的操作。执行故障切换或切换后，辅助数据库将用作新的主数据库并成为活跃数据库。
如果数据库技术支持此功能，则主数据库和辅助数据库都可以是活跃数据库，这称为“活跃-活跃”模式。在这种情况下，应用可以任意连接到其中一个数据库，因为这两个数据库都可用于状态管理。在双活模式下，如果只有一个活跃数据库变得不可用，则灾难恢复不需要执行故障切换。这是因为如果只有一个活跃数据库不可用，另一个活跃数据库仍将继续可用。双活模式不在本文的介绍范围之内，因为 SQL Server 不支持此模式。
备用模式：热备用、暖备用、冷备用和无备用
主数据库必须正在运行并且能够运行 DML 语句，才能成为活跃数据库。辅助数据库则不需要运行；它可以关停。如果辅助数据库未运行，则从灾难中恢复所需的时间会增加，因为在用作新的主数据库之前，此数据库必须先进入运行状态。
设置辅助数据库有以下几种不同的模式：
- 热备用：辅助数据库已启动并且正在运行，可供客户进行连接。主数据库的最新更改始终在其可用时立即应用。
- 暖备用：辅助数据库已启动并且正在运行，但并非所有主数据库的更改都必须已应用。
- 冷备用：辅助数据库未运行。首先需要启动辅助数据库，然后同步到最新的可用状态。
- 无备用：首先必须安装并启动数据库软件，然后应用主数据库的所有更改。此模式是最便宜的模式，因为它在没有需要时不会消耗资源，但与其他模式相比，它成为新的主数据库所需的时间最长。
DR 策略
以下部分将介绍 Microsoft SQL Server 支持的 DR 策略。
恢复策略维度
在选择或实施数据库灾难恢复策略时，需要考虑几个关键维度。每个维度都有一个范围，灾难恢复策略的处理方式和预期结果取决于这些范围点的选择。这些关键维度如下：
- 目标恢复点 (RPO)：可能由于重大突发事件而丢失应用中数据的最长可接受时长。此维度因数据的使用方式而异。RPO 可以表示为主数据库不可用的时长（秒、分钟或小时），也可以表示为可识别的处理状态（上次完整备份或上次增量备份）。无论以哪种方式指定 RPO，灾难恢复策略都必须实施特定措施，以满足 RPO 的要求。最苛刻的情况是将其设为最后提交的事务，这意味着主数据库和辅助数据库之间不允许出现任何数据损失。
- 目标恢复时间 (RTO)。 可以接受的最长应用离线时间。 此值通常指定为较大的服务等级协议的一部分。RTO 通常表示为主数据库不可用的时长，例如，应用必须在 5 分钟内完全可正常运行。最苛刻的情况是将其设为即时，这要求应用用户察觉不到灾难恢复的发生。
- 单点故障网域。您可以自行决定是否将某个区域视为灾难恢复要求的单点故障网域。如果您将某个区域设为单点故障网域，则必须设置灾难恢复，以使实际设置涉及两个或多个区域。如果包含主数据库的区域出现故障，则不同区域中的辅助数据库可以用作新的主数据库。如果将某个地区设为单点故障网域，则可以为单个区域内的地区设置灾难恢复。如果某个地区出现故障，则灾难恢复会使用第二个地区并使新的主数据库在其中可用。
确定这些关键维度相当于在费用和质量之间做出选择。 RTO 和 RPO 越低，灾难恢复解决方案费用越高，因为要使用更多的有效资源。以下各部分将介绍几种可选的灾难恢复策略，这些策略表示 Microsoft SQL Server 数据库环境中的维度点。
SQL Server 的 DR 策略
业务连续性和数据库恢复 - SQL Server 介绍了可用于实施灾难恢复策略的可用性功能。
预备知识
SQL Server 可以在 Windows 和 Linux 上运行。然而，并非所有可用性功能均可在 Linux 上使用。 SQL Server 具有多个版本，但并非每个版本都提供所有的可用性功能。
SQL Server 区分实例与数据库。实例是指执行指令的 SQL Server 软件，而数据库是指由 SQL Server 实例管理的数据集。
Always On 可用性组
Always On 可用性组提供数据库级层的保护。一个可用性组具有两个或多个副本。其中一个副本是具有读写访问权限的主副本，其它的副本是能够提供读取访问权限的辅助副本。每个数据库副本均由独立的 SQL Server 实例来管理。一个可用性组可以包含一个或多个数据库。 可用性组中可以包含的数据库数量以及受支持的辅助副本数量取决于 SQL Server 的版本。一个可用性组中的所有数据库都会同时进行相同的生命周期更改。可用性组采用“活跃-非活跃”模式，因为只有主数据库支持写入访问。
发生故障切换时，一个辅助副本将成为新的主副本。 由于可用性组包括独立的 SQL Server 实例，因此在事务日志中捕获的所有操作都在副本中可用。事务日志中未捕获的更改则需要手动同步，例如 SQL Server 实例级层登录或 SQL Server Agent 作业。为了提供数据库级层保护和 SQL Server 实例保护，您需要设置故障切换集群实例 (FCI)。下文中的 Always On 故障切换集群实例部分将介绍此部署架构。
您可以使用侦听器来保护应用免受角色更改影响。侦听器支持连接到可用性组的应用。在任何时候，应用都不知道管理主数据库或辅助副本的是哪个 SQL Server 实例。侦听器要求客户至少使用经过更新的 .NET 3.5 版本，或者 4.0 及更高版本，如业务连续性和数据库恢复 - SQL Server 中所述。
可用性组依赖于底层抽象层来提供其功能。可用性组在 Windows Server 故障切换集群 (WSFC) 中运行，如 Windows Server 故障切换集群与 SQL Server 中所述。运行 SQL Server 实例的所有节点必须是同一 WSFC 的一部分。
事务会从主数据库发送到所有辅助副本。 发送事务有两种模式：同步和异步。 您可以单独配置每个副本以使用任意一种模式。在同步发送模式下，只有当主数据库上的事务在同步关联的所有辅助副本上成功时，该事务才会成功。 在异步模式下，即使并非所有辅助副本都应用了主数据库上的事务，该事务也可以成功。
您选择的发送模式会影响可能的 RTO、RPO 和备用模式。例如，如果事务以同步模式发送到所有副本，则所有副本都处于完全相同的状态。由于所有副本完全同步，因此满足最苛刻的 RPO（最近的事务）。辅助副本采用热备用模式，因此任何副本都可以立即用作主数据库。
故障切换可以自动执行或手动执行。如果所有副本完全同步，则可以自动执行故障切换。对于前面的示例而言，这是可能实现的，因为所有副本始终完全同步。
下图展示了单个区域中的 Always On 可用性组。
可用性组表示为跨多个地区的矩形。这种表示方式仅用于表明所有数据库都属于同一可用性组。可用性组不是云资源，因此不在节点或任何其他类型的资源中实现。
Always On 故障切换集群实例
为了防止节点故障，您可以使用故障切换集群实例 (FCI) 而不是独立的 SQL Server 实例。有两个或更多的节点运行 SQL Server 实例以管理数据库（主数据库或辅助数据库）。这些管理数据库的节点构成故障切换集群。集群中的一个节点是运行 SQL Server 实例的活跃节点，其他节点不运行 SQL Server 实例。当运行 SQL Server 实例的节点发生故障时，集群中的另一个节点将启动一个 SQL Server 实例，从而接管数据库管理（节点故障切换）。这个自动启动 SQL Server 实例的过程提供了高可用性功能。
FCI 集群显示为单个单元，访问集群的客户不会看到节点之间的故障切换，除非出现短时间不可用的情况。发生节点故障切换时不会造成数据丢失。在出现故障的 SQL Server 实例中运行的所有内容都将转移到同一集群中的另一个 SQL Server 实例中。例如，SQL Server Agent 作业或关联的服务器将转移到另一个实例。
FCI 集群节点可以在不同的 Google Cloud 地区中进行设置。此架构不仅为节点故障提供了高可用性，也为地区故障提供了高可用性。DR 部署替代方案部分展示了此策略的示例部署。
即使不同节点管理同一数据库并共享该数据库，FCI 集群的节点之间也不需要公共存储空间。SQL Server 使用存储空间直通 (S2D) 功能来管理专用节点磁盘上的数据库。如需了解详情，请参阅配置 SQL Server 故障切换集群实例。
下图展示了上一部分中具有 FCI 而不是独立 SQL Server 实例的 Always On 可用性组的示例。每个 FCI 都有一个活跃的 SQL Server 实例用于管理数据库。
与可用性组相同，FCI 表示为矩形。 这种表示方式仅用于表明节点都属于同一 FCI。FCI 不是云资源，因此不在节点或任何其他类型的资源中实现。
如需了解更详细的介绍，请参阅 Always On 故障切换集群实例 (SQL Server)。
分布式可用性组
分布式可用性组是一种特殊类型的可用性组。分布式可用性组跨两个可用性组，其中一个是主可用性组，另一个是辅助可用性组。分布式可用性组可以通过同步和异步模式将事务从主可用性组转发到辅助可用性组。
虽然每个可用性组都有自己的主数据库，但并不采用“活跃-活跃”部署。只有主可用性组的主数据库才能接收写入操作。辅助可用性组的主数据库称为转发器。转发器从主可用性组接收事务，并将这些事务转发到辅助可用性组的辅助数据库。从主可用性组到辅助可用性组的故障切换将使新的主可用性组的主数据库可供写入操作访问。
主可用性组和辅助可用性组不必位于同一位置，也不必采用相同的操作系统。但是，每个可用性组都必须安装一个侦听器。分布式可用性组本身没有监听器。分布式可用性组不要求两个可用性组位于同一 WSFC 中。SQL Server 的功能包含分布式可用性组正常运行所需的所有功能，不需要额外安装底层组件。
一个分布式可用性组跨两个可用性组，而一个可用性组可以同时属于两个分布式可用性组。这种可能性支持不同的拓扑结构。一种是跨多个位置从可用性组到可用性组的菊花链拓扑。另一种是树状拓扑，其中主可用性组可以同时属于两个不同且独立的分布式可用性组。
分布式可用性组是跨多个操作系统实施灾难恢复的主要方法。例如，可以在 Windows 上设置主可用性组，在 Linux 上设置相应的辅助可用性组，这两个可用性组构成一个分布式可用性组。
下图展示了属于一个分布式可用性组的两个可用性组。
可用性组 1 是主可用性组，可用性组 2 是辅助可用性组。
与 FCI 相同，分布式可用性组表示为矩形。这种表示方式仅用于表明可用性组都属于同一分布式可用性组。与可用性组相同，分布式可用性组也不是云资源，因此不在节点或任何其他类型的资源中实现。
如需了解详情，请参阅分布式可用性组。
日志传送
当 RTO 和 RPO 不那么严格（低 RTO 和/或最近 RPO）时，事务日志传送是 SQL Server 可用性功能，因为主数据库与其辅助数据库之间的状态差异要大得多。 状态差异较大的原因在于事务日志文件包含许多状态更改。由于事务日志文件是异步传送的，必须完整地应用于辅助数据库，因此延迟时间的差异也很大。
事务日志文件由主数据库创建并进行备份，例如备份到 Cloud Storage。每个事务日志文件都会被复制到所有辅助数据库并应用。由于辅助数据库滞后于主数据库，因此它们处于暖备用模式。您必须手动将事务日志未捕获的对象和更改应用于辅助数据库，以建立完整同步，避免数据丢失。
SQL Server Agent 自动执行创建、复制和应用事务日志的整个过程。每个数据库必须单独设置日志传送。如果一个可用性组管理多个数据库，则必须设置多个日志传送过程。
由于不提供自动化支持，所以在发生故障时，您必须手动启动灾难恢复过程。此外，侦听器不会从主数据库和辅助数据库中抽象出客户访问。在故障切换发生时，客户必须能够在灾难恢复后连接到新的主数据库，自行应对一个数据库从辅助数据库转变为新的主数据库的角色变化。您可以独立于 SQL Server 实例构建单独的抽象，例如浮动 IP 地址，如浮动 IP 地址的最佳做法中所述。
由于日志传送是手动过程，因而您可以有意地将已复制的日志文件延迟应用于辅助数据库（这与立即应用更改的可用性组和分布式可用性组不同）。例如，您可以在解决主数据库上的数据修改错误之后，再将其应用于辅助数据库。在这种情况下，解决数据修改错误之前，尚未应用修改的辅助数据库无法成为主数据库。解决之后则可以继续进行正常处理。
与分布式可用性组相同，您可以将日志传送用于跨平台解决方案，例如主数据库在 Linux 上运行，而辅助数据库在 Linux 和 Windows 上运行的解决方案。
下图展示了使用日志传送的跨平台部署。请注意，此拓扑中不存在跨区域通用配置，这与分布式可用性组相同。
可用性组位于不同的区域，其中一个在 Linux 上运行，另一个在 Windows 上运行。
如需详细了解 SQL Server 日志传送，请参阅关于日志传送 (SQL Server)。
结合 SQL Server 可用性功能
您可以通过不同组合部署 SQL Server 可用性功能。例如，在前面的用例中，日志传送可以与安装在不同操作系统上的不同可用性组结合使用。
以下列表列出了 SQL Server 可用性功能的可能组合：
- 将日志传送用于安装在相同操作系统上的多个可用性组。
- 构建使用 FCI 的主可用性组和仅使用 SQL Server 独立实例的辅助可用性组。
- 在附近的区域之间使用分布式可用性组，并在不同大洲的各个区域之间使用日志传送。
这些只是 SQL Server 可用性功能的一些可能的组合。
SQL Server 可用性功能非常灵活，支持根据特定需求对灾难恢复策略进行调整。
SQL Server 复制
SQL Server 复制通常不被视为可用性功能，但本部分简要介绍了如何将此功能用于灾难恢复。
复制功能支持创建和维护数据库副本。不同类型的 SQL Server 代理互相协作以捕获更改、传输捕获的更改以及将这些更改应用于副本。此过程是异步的，副本通常在不同程度上滞后于复制数据库。
例如，生产数据库可以拥有副本。在进行灾难恢复时，生产数据库是主数据库，副本是辅助数据库。SQL Server 复制功能无法判断数据库在用于灾难恢复时承担的角色。因此，复制功能没有为灾难恢复过程提供支持的操作，例如角色更改。灾难恢复过程必须与 SQL Server 功能分开实施，并由组织实施运行，因为没有客户访问抽象。
备份文件传送
备份文件传送是另一种灾难恢复实施策略。设置和持续更新辅助数据库的标准方法是对主数据库进行初始完整备份，然后对其进行增量备份。所有增量备份都以正确的顺序应用于辅助数据库。这种方法有很多变化形式，具体取决于增量备份的频率和备份文件的存储位置（全局位置或实际上在不同位置之间进行复制）。
在将主数据库的状态更改复制到任何辅助数据库时，此策略不涉及任何 SQL Server 可用性功能。 它不使用日志传送所使用的 SQL Server Agent。
如需了解详情，请参阅“示例：备份和恢复灾难恢复策略”部分。
以下解决方案包含详细的 SQL Server 备份和恢复说明：使用 Microsoft SQL Server 备份在 Compute Engine 上进行时间点恢复。
与上一部分中介绍的复制方法相比，复制和备份文件传送的共同之处在于，灾难恢复过程是在 SQL Server 功能集外部实现的，并且与其分开实施。 从传送捕获的更改的角度来看，SQL Server 复制更方便，因为它通过 SQL Server Agent 自动实现这一过程。
关于数据库生命周期和应用生命周期之间的交互的说明
数据库故障切换不是完全独立的，并且与访问数据库的应用无关。原则上，存在两种故障场景。
首先，应用在数据库故障切换时保持运行。从主数据库不可用到新的主数据库正常运行期间，应用完全无法访问数据库。现有连接失败，并且无法建立新的连接。在此期间，应用无法为其客户提供服务，至少对于需要访问数据库的功能是如此。应用需要确定新的主数据库何时可用，以便其继续进行正常处理。
应用可以在数据库之外具有状态，例如在主内存缓存中。应用需要确保缓存与新的主数据库保持一致（同步）。如果故障切换期间根本没有丢失事务，则缓存可能是一致的，无需进一步维护。但是，如果在故障切换期间发生事务（数据）丢失，则缓存可能与新的主数据库不一致。类似的情况也适用于共享状态，例如，数据库中的某些数据也是队列中的部分消息或文件系统中的部分文件。关于数据一致性的内容不在本文档的介绍范围之内，因为它与数据库灾难恢复没有直接关系。
其次，一个或多个应用可能会在主数据库不可用的同时也变得不可用。例如，如果某个区域离线，则在该区域中运行的应用系统将与该区域中的主数据库同样不可用。在这种情况下，您还必须恢复该应用，而不仅仅是主数据库系统。在启动数据库灾难恢复过程时，您需要启动类似的应用恢复过程。恢复后的应用必须连接到新的主数据库并重新配置（例如浮动 IP 地址）。关于应用恢复的内容不在本文档的介绍范围之内。
灾难恢复的备份和恢复之间的关系
数据库备份是独立的，与数据库灾难恢复互不相关。数据库备份的目的是能够恢复一致的状态，例如应对数据库中数据丢失或损坏的情况，或者由于应用故障或代码错误而必须恢复先前状态的情况。如需了解如何在 Google Cloud 中进行备份、归档和恢复，请参阅使用 Microsoft SQL Server 备份在 Compute Engine 上进行时间点恢复。
以下部分介绍如何将备份用作实现数据库灾难恢复的一种可能机制。在这种情况下，您需要将备份文件复制到辅助数据库的位置，以使辅助数据库能够被恢复。但是，备份文件不是灾难恢复的先决条件；上文中关于可用性功能的部分介绍了替代方案。
高可用性和灾难恢复
高可用性和灾难恢复的共同之处在于它们为数据库不可用提供了解决方案。如果主数据库变得不可用，则辅助数据库将成为一致且可用的新主数据库。
高可用性和灾难恢复之间的区别在于单点故障网域。高可用性能够解决区域内的中断问题，例如单个地区故障或节点故障。高可用性解决方案可在同一区域内的另一个地区提供新的主数据库。此外，高可用性可解决节点故障，而不仅仅是数据库故障。 如果运行 SQL Server 实例的节点出现故障，则可以使用新的节点运行新的 SQL Server 实例（请参阅 Always On 故障切换集群实例部分中的介绍）。
灾难恢复涉及至少两个区域。它解决了整个区域不可用的情况。灾难恢复可以在另一个区域提供新的主数据库。
SQL Server 高可用性功能同时支持高可用性和灾难恢复解决方案。单个可用性组可以跨一个区域内的多个地区及自身所在的多个区域。可用性组可以包含故障切换集群实例以解决高可用性问题。
SQL Server 可以在一个区域内建立多个可用性组以实现高可用性及解决地区故障，并将其与跨区域的日志传送相结合以解决灾难恢复问题。
DR 部署替代方案
以下部分展示了一些上文未详细介绍的灾难恢复拓扑。这些拓扑可满足不同的 RPO 和 RTO 要求。下文并未列出所有可能的拓扑。
区域内 DR 和 HA
此部署是包含 FCI 的可用性组的一种变化形式，其位于包含三个地区的区域内。在此方案中，地区被视为单点故障网域。
与上文介绍的部署相比，此方案中的每个 FCI 由三个节点组成，其中每个节点在不同的地区中运行。此设置的好处在于，任意一个或两个地区都可以发生故障，而不需要灾难恢复过程。
下图展示了此设置。
FCI 跨所有地区，每个 FCI 中都有一个正在运行的 SQL Server 实例访问相应的数据库。另外还有两个未在任何 FCI 中运行的 SQL Server 实例，它们可在地区出现故障时启动。数据库跨所有地区，因为每个数据库使用给定 FCI 中所有节点的磁盘。为清楚起见，图中未显示应用。
区域间灾难恢复：跨区域的可用性组
在此方案中，可用性组在 Windows Server 故障切换集群上运行，并跨两个区域。区域被视为单点故障网域。
下图展示了此设置。
为了解决潜在的延迟时间问题，您可以将区域 R1 中的副本配置为使用同步事务传播，而区域 R2 中的副本配置为使用异步事务传播。
区域间 DR：备份文件传输
此方案使用备份文件传输。两个区域中的两个可用性组彼此关联。每个可用性组都由其副本同步接收事务，因此，每个区域的辅助副本都采用热备用配置。
下图展示了此设置。
但是，这两个可用性组通过备份文件传输进行连接。可用性组 AG1 是主可用性组，可用性组 AG2 是辅助可用性组。由于备份文件可供辅助可用性组使用，因此应用于其中。如需详细了解此方案，请参阅下一部分，“示例：备份和恢复 DR 策略”。
双位置和三位置拓扑
如果只有两个数据库（主数据库和辅助数据库，二者分别位于不同区域中），则在执行了故障切换，从新的主数据库开始运行到新的辅助数据库准备就绪期间，存在一段不受保护的时间。如果新的主数据库在辅助数据库尚未运行时变得不可用，则会出现硬停机时间，此故障只能在建立新的主数据库后恢复。这种情况同样适用于可用性组。
运行另一个辅助数据库或可用性组的第三个位置可以消除故障切换后的不受保护时间。此设置需要确保两个辅助数据库之一保留为辅助数据库，并重新分配给新的主数据库，从而避免数据丢失。与上文相同，这种情况也适用于可用性组。
DR 生命周期
无论哪种灾难恢复解决方案，都具有共同的生命周期步骤。
在实际的灾难恢复场景中，所有利益相关方（应用所有者、运营团队和数据库管理员）都需要知情并积极参与灾难恢复管理。利益相关方必须确定掌握决策权的人（有时称为“负责人”），以及他们应遵循的决策流程。此外，利益相关方必须就其术语和通信方式达成一致。
对启动故障切换过程做出决策
除非故障切换自动启动，否则利益相关方必须做出决策以启动故障切换。各利益相关方在决定启动故障切换时需要紧密协调。
启动故障切换的过程取决于几个因素，主要因素为主数据库变得不可用的根本原因。
如果灾难恢复过程所需的时间超过了解决主数据库不可用性的预期时间，那么故障切换将带来负面影响。 首先，您必须评估恢复主数据库是否可行。
对灾难恢复策略的测试效果越好，其实施速度就越快，决策时所需考虑的不确定性也越小，那么启动故障切换过程就越容易。
故障切换过程的执行
理想情况下，故障切换过程应进行定期测试，因此各利益相关方应熟知此过程。
掌握决策权的人必须了解正在进行的所有步骤以及可能出现的所有意外问题。掌握决策权的人负责推动故障切换过程，利益相关方负责支持掌握决策权的人。
您应保留统计信息以便进行事后分析并改进故障切换过程，这些信息包括故障切换过程步骤的活动时长、出现的问题以及在此期间产生的任何混乱。
缺少保护
如果您只有一个辅助数据库，则从新的主数据库可用且可正常运行起，直到新的辅助数据库设置完成的这段时间不存在 DR 保护。在此期间如果出现不可用，则可能导致出现硬停机时间，因为无法使用另一个数据库进行故障切换。如果出现这种情况，则必须设置另一个主数据库，RPA 是能够根据可用备份进行重建的最近时间点。
除非设置灾难恢复策略以使保护时刻存在，否则各利益相关方都必须了解缺少保护的时长，以便在进行设置或环境配置更改期间采取额外的预防措施。
如果应用对新的主数据库的访问被延迟到新的辅助数据库启动并运行之后，则可以避免这段不受保护的时间。在新的辅助数据库应用了主数据库的更改之后，主数据库就可供应用访问了。虽然这种方法可以避免应用不受 DR 保护的时间，但它会延迟灾难恢复过程完成。
避免脑裂的情况
应用无法同时访问主数据库和辅助数据库，对其执行 DML 操作，这一点关系重大。一旦发生这种情况，那么主数据库和辅助数据库中同一数据项的数据值不统一，就会产生数据不一致的问题（脑裂）。 如果主数据库在运行并且可以接收写入操作时变得不可用，则此架构尤为重要。如果不可用是由间歇性网络分区引起的，分区可以在任何时候停止，那么应用可能会再次进行访问。如果此时执行故障切换过程，则可能会丢失对旧的主数据库的更改，或者某些应用开始对新的主数据库执行操作，而其他应用仍在访问旧的主数据库。
在执行故障切换的过程中，所有应用都无法访问任何数据库，因此任何数据库都不会发生状态更改。故障切换完成后，只有一个数据库可接收写入操作，即新的主数据库。
完成声明
故障切换过程完成后，掌握决策权的人需要明确通知所有利益相关方该过程已完成。完成后出现的任何问题都应被视为单独的事件，不再作为故障切换过程的一部分，而应进行常规处理。该问题可能是由故障切换过程引发的后续问题，也可能是完全独立的问题。但是，完成故障切换过程后解决此问题的方法可能与执行故障切换过程期间解决此问题的方法不同。
事后分析和报告
为了改进故障切换过程并供未来参考，请及时安排事后分析，以记录重要方面、重要发现和操作项。
编写一份报告，汇总灾难恢复事件、根本原因以及采取的所有操作。如需贯彻监管要求，此报告须强制编写。
DR 测试和验证
由于灾难恢复不属于日常操作，因此必须定期测试 DR 解决方案，以确保其在实际需要时能够正常运行。
测试频率取决于运营要求，因数据库、应用和企业而异。此外，如果对所选灾难恢复解决方案所依赖的系统进行了环境更改（如网络配置更改和基础架构组件更新），则此更改应触发灾难恢复测试。任何更改都可能导致灾难恢复解决方案失败，或可能需要调整灾难恢复过程。
您可以启动切换过程以进行手动测试，也可以按照混沌工程中所述的混沌工程方法自动测试。 通过手动测试，您可以在预计会出现较长停机时间的情况下将其对业务的影响降至最低。
测试的一个重要方面是收集明确的统计信息。您需要考虑以下这些重要统计信息：
- 实际恢复时间：测量实际恢复时间并将其与 RTO 进行比较。
- 实际恢复点：观察实际恢复点并将其与 RPO 进行比较。
- 故障检测时间：DBA 或运营团队认识到需要执行故障切换所花费的时间。
- 恢复启动时间：检测到故障后启动故障切换过程所花费的时间。
- 可靠性：故障切换是否按照应有的过程执行，或者是否偏离该过程？是否出现需要调查、有可能导致恢复策略发生变化的意外问题？
根据收集到的统计信息，您可能必须调整或改进故障切换过程，以更好地匹配预期的 RPO 和 RTO。
示例：备份和恢复 DR 策略
以下部分展示了备份和恢复灾难恢复策略的示例。此方案最大限度地减少了对 SQL Server 可用性功能的使用，以展示指定 DR 备份和恢复策略所需完成的工作，并介绍在更自动化的设置中未涉及的方面。此方案引用相关解决方案，即使用 Microsoft SQL Server 备份在 Compute Engine 上进行时间点恢复。
使用场景
主 Always On 可用性组位于区域 R1 中并可在其中运行。 辅助 Always On 可用性组被添加到区域 R2 中，以提供额外的跨区域保护，并可用作故障切换或切换的目标。
策略
灾难恢复策略以数据库备份为基础。首先进行初始完整备份，随后进行差分备份。备份将在执行时应用于辅助 Always On 可用性组。所有备份都存储在 Cloud Storage 存储分区中。
在此示例中，完成故障切换后，在 R1 中新的辅助 Always On 可用性组可运行之前，允许 R2 中新的主 Always On 可用性组在有限时间内处于活跃状态且不受保护。
由于每个区域中的 Always On 可用性组均有资格用作生产 Always On 可用性组，因此不必进行回退。
RTO 和 RPO
在此示例中，RPO 最多定义为 60 分钟，因此差分备份每 60 分钟进行一次。
RTO 未明确设置为某个时长，但应尽可能小，最好设为“即时”。辅助可用性组必须设置为热备用。如果采用热备用，则所有备份会立即应用，因此故障切换不会延迟。
简要的 DR 策略
以下部分概述了 DR 策略。这部分内容比较简短，着重介绍基本步骤。
初始设置
- 在区域 R2 中创建辅助 Always On 可用性组。
- 阻止应用访问辅助可用性组，以避免意外出现脑裂情况。
- 在 Cloud Storage 中创建备份文件存储分区 B1，以存储 R1 中 Always On 可用性组的初始完整备份以及后续每小时的差分备份。您必须建立正确的差分备份顺序，以便将备份按推断出的正确顺序应用于辅助可用性组。使用命名惯例是一种可行的方法，此方法根据各种文件名中的日期和时间来建立正确的时间顺序。
启动策略
- 将完整备份应用于区域 R2 中的辅助 Always On 可用性组。
- 当差分备份可用时，立即将这些备份应用于 R2 中的辅助 Always On 可用性组。为满足 RTO，应用过程需尽快执行。
- 初始完整备份和所有增量备份应用完成后，辅助 Always On 可用性组准备就绪。
- 执行从主可用性组到辅助可用性组的切换以测试 DR 策略。测试期间至少应有一个可用的增量备份。
故障切换或切换的案例
在 R2 中，基本步骤如下：
- 确保将最新的差分备份应用于 R2 中的辅助 Always On 可用性组。
- 将 R2 指定为新的主 Always On 可用性组。
- 创建新的存储分区 B2，将完整备份作为基准，并开放新的主可用性组以供应用访问。
- 开始进行差分备份。
在 R1 中，基本步骤如下：
- 移除存储分区 B1，因为不再需要使用它。
- 当 R1 中的 Always On 可用性组再次可用时（作为新的辅助 Always On 可用性组），阻止应用访问，并从数据库中移除所有数据或将其重置为初始（空）状态（除非必须重新创建）。
- 应用 R2 中新的主 Always On 可用性组的完整备份，并在差分备份可用时立即应用（存储在存储分区 B2 中）。
可能的改进
DR 策略的一个可能的改进是避免在故障切换或切换后进行完整备份，同时仍能够快速设置新的辅助可用性组。此项改进每周执行一次完整备份，并创建一个每周存储分区，以存储本周的完整备份以及本周的所有后续差分备份，而不是执行一次完整备份及后续差分备份。新的主可用性组必须仅在故障切换（而不是完整备份）完成后创建差分备份，并将其添加到存储分区。新的辅助可用性组仅应用当周存储分区中的所有备份。如果采用这种每周一次的方法，您需要执行清理或清除策略以移除过时的备份。
另一项改进利用了新的辅助可用性组是原来的主可用性组这一现实。如果数据库存在且在再次可用后仍可运行，则恢复到其上次差分备份的时间点可避免必须使用上次完整备份对其进行完整恢复，如将 SQL Server 数据库恢复到某个时间点（完整恢复模式）中所述。 此方案可减少工作量和新的主可用性组不受保护的时间。
生产最佳做法
此解决方案未指定 Always On 可用性组中的 SQL Server 实例是独立的实例还是 FCI 实例。使用的实例类型需要在实现此解决方案之前加以确定。
故障切换完成后、新的辅助 Always On 可用性组可运行之前的这段时间不存在 DR 保护。您应在第三个区域中设置第三个 Always On 可用性组。
此外，您应实施监控以确保能够检测到任何故障或错误。关于监控的内容不在本文档的介绍范围之内，但实施监控对于正常运行灾难恢复解决方案至关重要。
后续步骤
- 配置 SQL Server Always On 可用性组。
- 在 Compute Engine 上部署多子网 SQL Server 2016 Always On 可用性组。
- 配置 SQL Server 故障切换集群实例。
- 运行 Windows Server 故障切换集群。
- 如何为 .NET 应用启用 Cloud Logging、Cloud Monitoring 和 Error Reporting
- 安装 Cloud Monitoring 代理。
- 探索有关 Google Cloud 的参考架构、图表和最佳实践。查看我们的 Cloud Architecture Center。