业务连续性和数据库恢复 - SQL Server

适用于：SQL Server 2016 (13.x) 及更高版本

本文概述 Windows 和 Linux 上 SQL Server 中高可用性和灾难恢复的业务连续性解决方案。

部署 SQL Server 的每个人都需要确保业务和最终用户需要这些实例时，所有任务关键型 SQL Server 实例和数据库中的数据库都可用，无论是在常规营业时间还是全天候提供。 其目标是尽量减少或杜绝中断，保持业务正常运行。 此概念也称为业务连续性。

SQL Server 2017 （14.x） 及更高版本引入了可用性功能和增强功能。 最大的添加是对 Linux 分发版上的 SQL Server 的支持。 有关 SQL Server 中新功能的完整列表，请参阅以下文章：

本文重点介绍 SQL Server 2017（14.x）及更高版本中的可用性方案，以及新的和增强的可用性功能。 这些方案包括可跨 Windows Server 和 Linux 上的 SQL Server 部署的混合方案，以及可以增加数据库可读副本数的混合部署。

虽然本文不包括 SQL Server 外部的可用性选项（例如虚拟化），但此处讨论的所有内容都适用于来宾虚拟机中的 SQL Server 安装，无论是在公有云中还是由本地虚拟机监控程序服务器托管。

使用可用性功能的 SQL Server 方案

可以通过不同的方式使用 Always On 可用性组、故障转移群集实例和日志传送，这不仅仅用于可用性。 有四种主要方法可以使用可用性功能：

• 高可用性
• 灾难恢复
• 迁移和升级
• 扩大一个或多个数据库的可读副本

以下各节介绍每个方案的相关功能。 未涵盖的一项功能是 SQL Server 复制。 虽然 SQL Server 复制未正式指定为 Always On 保护伞下的可用性功能，但它通常用于在某些方案中使数据冗余。 Linux 上的 SQL Server 不支持合并复制。 有关详细信息，请参阅 Linux 上的 SQL Server 复制。

高可用性

如果发生本地数据中心或云中的单个区域的问题，请务必确保 SQL Server 实例或数据库可用。 本部分介绍 SQL Server 可用性功能如何提供帮助。 Windows Server 和 Linux 上都提供了此处描述的所有功能。

可用性组

可用性组（AG）通过将数据库的每个事务发送到另一个实例或副本来提供数据库级保护，该实例或 副本包含处于特殊状态的数据库副本。 可以在 Standard 或 Enterprise 版本上部署 AG。 参与 AG 的实例可以是独立实例，也可以是故障转移群集实例（FCI，将在下一部分中介绍）。 由于在事务发生时将它发送到副本，建议在需要较低恢复点目标和恢复时间目标的情况下使用 AG。 副本之间的数据移动可以是同步的或异步的，Enterprise 版本允许同步多达三个副本（包括主要副本）。 AG 具有一个数据库的完全读/写副本且位于主要副本上，而所有次要副本都不能直接从最终用户或应用程序接收事务。

在 SQL Server 2022 (16.x) 之前，AG 仅提供数据库级保护，而不提供实例级保护。 未记录在事务日志中或未在数据库中配置的任何内容，都必须为每个辅助副本手动同步。 必须手动同步的对象的一些示例为实例级登录、链接服务器和 SQL Server 代理作业。

在 SQL Server 2022（16.x）及更高版本中，除了实例级别之外，还可以在 AG 级别管理元数据对象，包括用户、登录名、权限和 SQL Server 代理作业。 有关详细信息，请参阅什么是包含的可用性组？

AG 还有一个名为侦听器的组件，该组件允许应用程序和最终用户在不知道哪个 SQL Server 实例承载着主要副本的情况下进行连接。 每个 AG 都有自己的侦听器。 虽然侦听器的实现在 Windows Server 与 Linux 上略有不同，但它们都提供相同的功能和可用性。 下图显示了使用 Windows Server 故障转移群集（WSFC）的基于 Windows Server 的 AG。 OS 层的基础群集是 Linux 还是 Windows Server 上的可用性所必需的。 该示例显示了一个简单配置，其中包含两个服务器或将 WSFC 作为基础群集的节点。

就副本而言，Standard 版本和 Enterprise 版本具有不同的最大值。 Standard 版本中的 AG（称为基本可用性组）支持两个副本（一个主要副本和一个次要副本），且 AG 中只有一个数据库。 Enterprise 版本不仅允许在一个 AG 中配置多个数据库，而且拥有的副本总数可多达 9 个（1 个主要副本，8 个次要副本）。 Enterprise 版本还提供了其他可选权益，如可读辅助副本和备份次要副本的能力等。

在可用性方面，AG 可提供自动或手动故障转移。 如果配置了同步数据移动，并且主要副本和次要副本上的数据库处于同步状态，则会发生自动故障转移。 只要使用侦听器，并且应用程序使用受支持的 .NET Framework 版本（3.5 带有 Service Pack 1，或 4.6.2 及更高版本），故障转移应以最小影响进行处理，利用侦听器时对最终用户几乎没有影响。 可将使次要副本成为新的主要副本的故障转移配置为自动或手动，且测量的单位通常为秒。

以下列表突出显示了 Windows Server 与 Linux 上的 AG 的一些差异：

由于基础群集在 Linux 和 Windows Server 上的工作方式，所有 AG 故障转移（手动或自动）都通过 Linux 上的群集完成。 而在基于 Windows Server 的 AG 部署中，手动故障转移必须通过 SQL Server 完成。 自动故障转移则由 Windows Server 和 Linux 上的基础群集处理。

• 对于 Linux 上的 SQL Server，应配置至少包含三个副本的可用性组（AG），因为基础群集的工作机制如此。

• 在 Linux 上，每个侦听器使用的公用名在 DNS 中定义，而不是在群集中定义，就像在 Windows Server 上一样。

SQL Server 2017 （14.x） 引入了以下对 AGs 的功能和增强：

• 群集类型
• REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT
• 增强的 Microsoft 分布式事务处理协调器 (DTC) 支持基于 Windows Server 的配置
• 只读数据库的其他横向扩展方案（本文后面进行了介绍）

可用性组群集类型

通过名为故障转移群集的功能启用 Windows Server 中群集的内置可用性形式。 通过它，你可生成与 AG 或 FCI 一起使用的 WSFC。 SQL Server 提供群集感知资源 DLL，这些 DLL 为 AG 和 FCI 提供集成。

Linux 上的 SQL Server 支持多种群集技术。 Microsoft 支持 SQL Server 组件，而我们的合作伙伴则支持相关的群集技术。 例如，除 Pacemaker 以外，Linux 上的 SQL Server 还支持将 HPE Serviceguard 和 DH2i DxEnterprise 作为群集解决方案。

基于 Windows 的故障转移群集和 Linux 群集解决方案更相似，而不是不同。 两者都提供这样一种方式：使用多个单独的服务器，在配置中将它们合并，从而提供可用性；此外两者都具有资源、约束（尽管实施方式不同）、故障转移等概念。

例如，为支持 Pacemaker 的 AG 和 FCI 配置（包括自动故障转移等），Microsoft 为 Pacemaker 提供了 mssql-server-ha 包，它与 WSFC 中的资源 DLL 类似但不完全相同。 WSFC 和 Pacemaker 之间的区别之一是 Pacemaker 中没有网络名称资源，该组件有助于提取 WSFC 上的侦听器名称（或 FCI 名称）。 在 Linux 上使用 DNS 进行名称解析。

由于群集堆栈的差异，SQL Server 2017（14.x）及更高版本中的 AG 需要处理 WSFC 本机处理的一些元数据。 例如，可用性组有三种 群集类型，这些群集类型 存储在 sys.availability_groupscluster_typecluster_type_desc 列中：

• WSFC
• 外部
• 无

要求高可用性的所有 AG 都必须使用基础群集，在 SQL Server 2017 (14.x) 和更高版本中则为 WSFC 或 Linux 群集代理。 对于使用基础 WSFC 的基于 Windows Server 的 AG，默认群集类型为 WSFC，无需设置它。 对于基于 Linux 的 AG，必须在创建 AG 时将群集类型设置为“外部”。 在创建 AG 后配置与 Linux 中的外部群集解决方案的集成，而在 WSFC 上，需在创建时进行集成。

Windows Server 和 Linux AG 都可使用“无”群集类型。 将群集类型设置为“无”，表示 AG 不需要基础群集。 这意味着 SQL Server 2017 (14.x) 是首个支持无群集 AG 的 SQL Server 版本，但其不利的一面是高可用性解决方案不支持此配置。

如果您只想添加数据库的额外只读副本，或者需要利用 AG 来支持迁移和升级，而不想处理基础群集甚至复制的复杂性，请考虑设置一个群集类型为 None 的 AG。 有关详细信息，请参阅 迁移和升级 和 读取缩放部分。

以下屏幕截图显示了对 SQL Server Management Studio（SSMS）中不同类型的群集类型的支持。 必须运行 17.1 版或更高版本。 以下屏幕截图来自版本 17.2：

REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT

SQL Server 2016 (13.x) 将 Enterprise 版本中支持的同步副本数从两个增加到了三个。 但是，如果一个次要副本同步，但另一个副本出现问题，则无法控制主副本的行为，无法选择是等待问题副本，还是继续进行。 在此方案中，即使辅助副本未处于同步状态，主副本仍可接收写入流量，从而导致次要副本数据丢失。

在 SQL Server 2017（14.x）及更高版本中，可以控制当存在同步副本 REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT时发生的情况的行为。 此选项的工作原理如下所示：

• 有三个可能的值： 0、 1和 2。
• 该值是必须同步的次要副本数，这对数据丢失、AG 可用性和故障转移具有影响。
• 对于 WSFC 和群集类型为 None，默认值为 0，可以手动将其设置为 1 或 2。
• 对于 External 的群集类型，群集机制默认设置此值，你可以手动替代该值。 对于三个同步副本，默认值为 1。

在 Linux 上，您可以在群集中的 AG 资源上配置 REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT 的值。 在 Windows 上，可以通过 Transact-SQL 设置它。

高于 0 的值可以确保更高的数据保护，因为如果所需的次要副本数不可用，则在该条件解决之前，主副本将不可用。 REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT 还会影响故障转移行为，因为如果次要副本的数量不正确或者未处于适当状态，则无法进行自动故障转移。 在 Linux 上，值 0 不支持自动故障转移，因此在 Linux 上使用同步和自动故障转移时，必须设置值高于 0 才能实现自动故障转移。 Windows Server 上的 0 是 SQL Server 2016 (13.x) 及更早版本中的行为。

增强的 Microsoft 分布式事务处理协调器支持

在 SQL Server 2016（13.x）之前，需要分布式事务（在封面下使用 DTC）的应用程序获得 SQL Server 的可用性的唯一方法是部署 FCI。 可通过以下两种方式之一执行分布式事务：

• 跨同一 SQL Server 实例中的多个数据库的事务。
• 跨多个 SQL Server 实例或可能涉及非 SQL Server 数据源的事务。

SQL Server 2016 (13.x) 引入了部分 DTC 支持，适用于涵盖后一种情况的 AG。 SQL Server 2017 (14.x) 对此进行了完善，对以上两种情况都提供 DTC 支持。

在 SQL Server 2017（14.x）及更高版本中，可以在创建可用性组（AG）后向其添加 DTC 支持。 在 SQL Server 2016（13.x）中，只能在创建 AG 时启用 DTC 支持。

故障转移群集实例

故障转移群集实例（FCI）为 SQL Server 的整个安装（称为 实例）提供可用性。 使用 FCI 时，如果基础服务器遇到问题，实例中的所有内容将移动到另一台服务器，包括数据库、SQL Server 代理作业、链接服务器等。 所有 FCI 都需要一些共享存储，即使存储是由网络定义的。 一个节点可以在任何给定时间运行并拥有 FCI 的资源。 在下图中，群集的第一个节点拥有 FCI。 它还拥有与其相关联的共享存储资源，实线表示与存储的关系。

故障转移后，所有权发生变化，如下图所示：

FCI 具有零数据丢失，但由于数据只有一个副本，基础共享存储是一个单点故障。 若要具有数据库的冗余副本，请结合使用 FCI 与其他可用性方法，例如 AG 或日志传送。 另一种方法必须以物理方式将存储与 FCI 分开。 当 FCI 故障转移到另一个节点时，它会在一个节点上停止运行并在另一个节点上启动。 此过程类似于关闭服务器并将其打开。

FCI 会经历正常的恢复过程。 它会提交任何需要提交的事务，并回撤任何不完整的事务。 因此，数据库从数据点到故障或手动故障转移的时间是一致的，因此不会丢失数据。 只有在恢复完成后，数据库才可用。 恢复时间取决于许多因素，通常比故障转移 AG 更长。 缺点是，在对 AG 进行故障转移时，可能需要执行额外的任务才能使数据库可用，例如启用 SQL Server 代理作业。

如同 AG 一样，FCI 提取承载它的基础群集节点。 FCI 始终保留相同的名称。 应用程序和最终用户永远不会连接到节点。 而是使用分配给 FCI 的唯一名称。 FCI 可作为一个托管主要副本或次要副本的实例加入 AG。

以下列表突出显示了 Windows Server 与 Linux 上的 FCI 的一些差异：

• 在 Windows Server 上，FCI 属于安装过程。 安装 SQL Server 后，在 Linux 上配置 FCI。
• Linux 仅支持每个主机一次安装 SQL Server，因此所有 FCI 都是默认实例。 Windows Server 支持每个 WSFC 具有最多 25 个 FCI。
• Linux 中 FCI 使用的公用名在 DNS 中定义，并且名称应与为 FCI 创建的资源相同。

日志传送

如果恢复点和恢复时间目标更灵活，或者数据库不是高度任务关键型，则日志传送是 SQL Server 中另一个经过验证的可用性功能。 基于 SQL Server 的本机备份，日志传送过程自动生成事务日志备份，并将其复制到一个或多个称为热备用状态的实例，然后自动将事务日志备份应用于该备用实例。 日志传送使用 SQL Server 代理作业自动执行备份、复制和应用事务日志备份的过程。

使用日志传送的最大优点是，它可以考虑到人为错误，因为可以延迟应用事务日志。 例如，如果有人发出UPDATE而没有包含WHERE子句，则备用系统可能没有进行变更，因此在修复主系统时可以切换到备用系统。 虽然日志传送易于配置，但始终手动从主服务器切换到称为 角色更改的热备用服务器。 通过 Transact-SQL 启动角色更改，就像 AG 一样，必须手动同步事务日志中未捕获的所有对象。 需要为每个数据库配置日志传送，而单个 AG 可以包含多个数据库。

与 AG 或 FCI 不同，日志传送没有角色更改的抽象，应用程序必须能够处理这些更改。 可以使用 DNS 别名 (CNAME) 等技术，但存在利弊，例如切换后 DNS 刷新需要一定的时间。

灾难恢复

主要可用性位置遭遇地震或洪水等灾难事件时，企业必须做好准备，在其他地方将系统联机。 本部分介绍 SQL Server 可用性功能如何帮助实现业务连续性。

可用性组

AG 的优点之一是使用单个功能配置高可用性和灾难恢复。 由于不需要确保共享存储也具有高可用性，可以更轻松地实现在一个数据中心内具有用于高可用性的本地副本，在其他数据中心内具有用于灾难恢复的远程备份，且每个备份都有单独的存储。 确保冗余的代价是具有额外的数据库副本。 下图显示了跨多个数据中心的 AG 示例。 一个主要副本负责确保所有次要副本保持同步。

在群集类型为 None 的 AG 外部，AG 要求所有副本都是同一基础群集的一部分，无论是 WSFC 还是外部群集解决方案。 在上图中，WSFC 被扩展至在两个不同的数据中心工作，这增加了复杂性，无论是使用 Windows Server 还是 Linux 平台。 跨距离延伸群集会增加复杂性。

SQL Server 2016 (13.x) 中引入了分布式可用性组，它允许 AG 跨越在不同的群集上配置的 AG。 分布式 AG 降低了节点必须全部位于同一个群集中这一要求，使配置灾难恢复更加容易。 有关分布式 AG 的详细信息，请参阅分布式可用性组。

故障转移群集实例

可以使用 FCI 进行灾难恢复。 与普通 AG 一样，必须将基础群集机制扩展到所有位置，从而增加复杂性。 对于 FCI，还需要考虑共享存储。 主站点和辅助站点需要访问同一磁盘。 若要确保 FCI 使用的存储存在于这两个站点中，请使用外部方法，例如硬件层上的存储供应商提供的功能。 或者，在 Windows Server 中使用存储副本。

日志传送

日志传送是用于为 SQL Server 数据库提供灾难恢复的最旧方法之一。 日志传送通常与 AG 和 FCI 一起使用，以提供经济高效且更简单的灾难恢复，而其他选项可能因环境、管理技能或预算而具有挑战性。 与日志传送的高可用性情景类似，许多环境延迟加载事务日志以考虑人为错误。

迁移和升级

当组织部署新实例或升级旧实例时，它不能容忍长时间的中断。 本部分讨论如何使用 SQL Server 的可用性功能来最大程度地减少计划内体系结构更改、服务器交换机、平台更改（如 Windows Server 到 Linux）或修补期间的停机时间。

可用性组

可以将包含一个或多个可用性组（AG）的现有实例升级到更高版本的 SQL Server。 虽然此升级需要一定数量的停机时间，但可以通过适当的计划量将其最小化。

如果要在不更改配置（包括作系统或 SQL Server 版本）的情况下迁移到新服务器，请将这些服务器作为节点添加到现有基础群集，然后将其添加到 AG。 一旦一个或多个副本处于正确状态，手动执行故障转移到新服务器。 然后，从 AG 中删除旧服务器并解除其授权。

分布式 AG 也是另一种迁移到新配置或升级 SQL Server 的方法。 由于分布式 AG 支持不同体系结构上的不同基础 AG，因此你可以从 Windows Server 2019 上运行的 SQL Server 2019（15.x）更改为在 Windows Server 2025 上运行的 SQL Server 2025（17.x）。

最后，群集类型为 None 的 AG 对于迁移或升级很有用。 不能在典型的 AG 配置中混合和匹配群集类型，因此所有副本都需要为 None 类型。 分布式 AG 可用于跨配置了不同群集类型的 AG。 不同的 OS 平台上也支持这种方法。

迁移和升级的所有 AG 变体都允许将数据同步过程——作为最耗时的工作部分——在一段时间内逐步展开完成。 当需要启动向新配置的转换时，切换会造成短暂的中断，而不是像长时间停机那样需要完成所有工作，包括数据同步。

在修补过程中，AG 可以通过手动将主副本故障转移到次要副本，从而在基础 OS 修补期间提供最小化的停机时间。 从作系统的角度来看，这样做在 Windows Server 上更为常见，因为基础 OS 的服务可能需要重启。 修补 Linux 有时需要重启，但不太常见。

最小化停机时间的另一种方法是 修补参与可用性组的 SQL Server 实例，具体取决于 AG 体系结构的复杂性。 首先修补次要副本。 一旦修补了正确数量的副本，手动将主副本故障转移到另一个节点以进行升级。 此时升级任何剩余的次要副本。

故障转移群集实例

FCI 本身无法协助进行传统的迁移或升级。 必须为 FCI 中的数据库配置 AG 或日志传送，并考虑所有其他对象。 但是，当你需要修补基础 Windows Server 时，Windows Server 下的 FCI 仍然是一种常用选项。 在您启动手动故障转移时，这种短暂的中断将取代 Windows Server 修补期间整个实例的不可用性。

可以将 FCI 就地升级到更高版本的 SQL Server。 有关详细信息，请参阅 升级故障转移群集实例。

日志传送

日志传送仍然是迁移和升级数据库的常用选项。 与 AG 相似，但在这种情况下使用事务日志作为同步方法，可在服务器切换之前启动数据传播。 切换时，一旦所有流量在来源处停止，则记录最终事务日志，并将其复制、应用到新配置。 此时，数据库即可联机工作。

日志传送通常更能容忍较慢的网络，虽然交换机可能比使用 AG 或分布式 AG 完成的交换机要长一些，但通常以分钟（而不是小时、天或周）来度量。

与 AG 类似，日志传送可以提供在维护时段切换到另一台服务器的方法。

其他 SQL Server 部署方法和可用性

还可通过另外两种方法部署 Linux 上的 SQL Server：容器和使用 Azure（或其他公有云提供程序）。 无论如何部署 SQL Server，都存在可用性的一般需求。 这两种方法在使 SQL Server 高度可用时具有一些特殊注意事项。

SQL Server 容器和 HA/DR 选项

SQL Server 容器部署 是简化跨环境的 SQL Server 预配、缩放和生命周期管理的一种方法。 容器是 SQL Server 的完整可运行镜像。

根据容器平台，例如，使用容器业务流程协调程序（如 Kubernetes）时，如果容器丢失，则可以再次部署该容器并将其附加到使用的共享存储。 虽然这确实提供了一些复原能力，但存在一些与数据库恢复相关的停机时间，并且不会真正高可用性，就像使用可用性组或 FCI 一样。

如果要为部署在 Kubernetes 或非 Kubernetes 平台上的 SQL Server 容器配置高可用性，可以使用 DH2i DxEnterprise 作为群集解决方案之一，基于该解决方案，可以在高可用性模式下配置 AG。 此选项提供高可用性解决方案所期望的恢复点目标 (RPO) 和恢复时间目标 (RTO)。

基于 Linux 的 VM 部署

Linux 可以与 Linux Azure 虚拟机上的 SQL Server 一起部署。 与本地安装一样，支持的安装需要使用隔离群集代理本身外部的失败节点。 节点隔离是通过隔离可用性代理提供的。 一些发行版将其作为平台的一部分提供，其他则依赖于外部硬件和软件供应商。 请查看首选的 Linux 分发版，了解提供了哪些形式的节点隔离，以便可以在公有云中部署受支持的解决方案。

有关安装 Linux 上的 SQL Server 的指南适用于以下发行版：

• 快速入门：在 Red Hat 上安装 SQL Server 并创建数据库
• 快速入门：安装 SQL Server 并在 Ubuntu 上创建数据库
• 快速入门：在 SUSE Linux Enterprise Server 上安装 SQL Server 并创建数据库

读取缩放

次要副本可用于只读查询。 有两种方法可以通过 AG 实现这些功能:

• 允许直接访问辅助数据库
• 配置只读路由，这需要使用侦听器。 SQL Server 2016 (13.x) 引入了通过使用轮循机制算法的侦听器负载均衡只读连接的功能，允许只读请求分布在所有可读副本中。

首次通过分布式可用性组 (AG) 在 SQL Server 2016（13.x）中引入了对数据库可读副本的扩展。 此功能不仅在本地提供数据库的只读副本，而且提供区域和全局副本，且配置最少。 此设置通过在本地执行查询来减少网络流量和延迟。 AG 每个主复制品都可以初始化另外两个 AG，即便它不是完全支持读/写的副本，并且每个分布式 AG 能最多支持 27 个可读数据副本。

在 SQL Server 2017（14.x）及更高版本中，可以使用群集类型为 None 的 AG 创建近乎实时的只读解决方案。 如果目标是将 AG 用于可读次要副本，而不是可用性，则此方法消除了在 Linux 上使用 WSFC 或外部群集解决方案的复杂性。 它通过更简单的部署方法提供了易于阅读的 AG 优势。

唯一的主要注意事项是，由于没有群集类型为 None 的基础群集，配置只读路由略有不同。 从 SQL Server 的角度来看，即使没有群集，仍然需要侦听器来路由请求。 使用主副本的 IP 地址或名称，而不是配置传统的侦听器。 然后，主副本路由只读请求。

从技术上来说，可以通过还原数据库 WITH STANDBY来配置日志传送暖备用服务器以供可读使用。 但是，由于事务日志需要独占使用数据库进行恢复，这意味着用户不能在这种时候访问数据库。 因此，日志传送并非理想解决方案，特别是在需要准实时数据的情况下。

与事务复制中所有数据都是实时的不同，在读取扩展场景中，每个辅助副本都是主副本的精确副本。 副本未处于可应用唯一索引的状态。 如果报告需要任何索引，或者数据需要操作，则必须在主副本的数据库中创建这些索引。 如果需要灵活性，复制是对可读数据而言较佳的解决方案。

跨平台和 Linux 分发互操作性

借助 Windows Server 和 Linux 上的 SQL Server 支持，本部分介绍它们如何协同工作以实现可用性以及其他目的。 它还介绍了包含多个 Linux 分发的解决方案的故事。

分布式可用性组

分布式 AG 旨在跨 AG 配置，无论 AG 下的两个基础群集是两个不同的 WSFC、Linux 发行版，还是一个在 WSFC 上，另一个在 Linux 上。 分布式 AG 是跨平台解决方案的主要方法。 分布式 AG 也是迁移的主要解决方案，例如，如果公司需要，可从基于 Windows Server 的 SQL Server 基础结构迁移到基于 Linux 的基础结构。 如前所述，AG，特别是分布式 AG，将最大程度地减少应用程序不可用的时间。 下图显示了跨 WSFC 和 Pacemaker 的分布式 AG 示例：

如果配置群集类型为 None 的可用性组 (AG)，则它可以跨越 Windows Server 和 Linux，同时支持多个 Linux 发行版。 由于此配置不是真正的高可用性，因此不要将其用于任务关键型部署。 而是将其用于读扩展或迁移和升级场景。

日志传送

日志传送基于备份和还原，因此 Windows Server 上的 SQL Server 数据库、文件结构和其他元素与 Linux 上的 SQL Server 没有区别。 可以在基于 Windows Server 的 SQL Server 安装与 Linux 安装之间以及 Linux 分发之间配置日志传送。 其他所有内容保持不变。

与 AG 一样，当源服务器位于较高 SQL Server 主版本时，日志传送不适用于较低主版本的目标。

总结

可以使用 Windows Server 和 Linux 上的相同功能，使 SQL Server 2017（14.x）和更高版本的实例和数据库高度可用。 除了本地高可用性和灾难恢复的标准可用性方案外，还可以通过使用 SQL Server 中的可用性功能来最大程度地减少与升级和迁移相关的停机时间。 AG 还可以提供数据库的额外副本作为同一体系结构的一部分，以横向扩展可读副本。 无论是部署新的解决方案还是考虑升级，SQL Server 均可提供所需的可用性和可靠性。

相关内容

• 什么是 Always On 可用性组？
• 安装 SQL Server 故障转移群集