Always On 可用性组 功能是一个提供替代数据库镜像的企业级方案的高可用性和灾难恢复解决方案。 Always On 可用性组可最大程度地提高一组用户数据库对企业的可用性。 “可用性组”针对一组离散的用户数据库（称为“可用性数据库”，它们共同实现故障转移）支持故障转移环境。 一个可用性组支持一组读写主数据库以及一至八组对应的辅助数据库。 （可选）可使辅助数据库能进行只读访问和/或某些备份操作。
使用已启用 Azure Arc 的 SQL Server，可在 Azure 门户中查看可用性组。
概述
可用性组支持的复制环境适用于一组离散用户数据库，称为“可用性数据库”。 可以创建可用性组以实现高可用性 (HA) 或读取缩放。 HA 可用性组是一组共同实现故障转移的数据库。 读取缩放可用性组是一组复制到其他 SQL Server 实例以实现只读工作负荷的数据库。 一个可用性组支持一组主数据库以及一至八组对应的辅助数据库。 辅助数据库不是备份。 应继续备份数据库及其事务日志。
提示
您可以创建主数据库的任何类型的备份。 也可以创建辅助数据库的日志备份和仅复制完整备份。 有关详细信息，请参阅卸载可用性组次要副本的受支持备份。
每组可用性数据库都由一个“可用性副本”托管。 存在两种类型的可用性副本：一个主要副本（托管主数据库）和一到八个次要副本（每个次要副本托管一组辅助数据库，并用作可用性组的潜在故障转移目标）。 可用性组在可用性副本级别进行故障转移。 可用性副本仅在数据库级别提供冗余（针对一个可用性组中的该组数据库）。 故障转移不是由诸如因数据文件丢失或事务日志损坏而使数据库成为可疑数据库等数据库问题导致的。
主副本使主数据库可用于客户端的读写连接。 主副本将每个主数据库的事务日志记录发送到每个辅助数据库。 此过程（称为“数据同步”）在数据库级别运行。 每个次要副本缓存事务日志记录（“硬化”日志），然后将它们应用到相应的辅助数据库。 主数据库与每个连接的辅助数据库独立进行数据同步。 因此，一个辅助数据库可以挂起或失败而不会影响其他辅助数据库，一个主数据库可以挂起或失败而不会影响其他主数据库。
或者，您可以配置一个或多个辅助副本以支持对辅助数据库进行只读访问，并且可以将任何辅助副本配置为允许对辅助数据库进行备份。
SQL Server 2017 引入了用于可用性组的两种不同的体系结构。 “AlwaysOn 可用性组”提供高可用性、灾难恢复和读取缩放均衡。 这些可用性组需要群集管理器。 在 Windows 中，故障转移群集功能提供群集管理器。 在 Linux 中可以使用 Pacemaker。 另一个体系结构是“读取缩放可用性组”。 读取缩放可用性组为只读工作负荷提供副本，但不提供高可用性。 读取缩放可用性组中没有群集管理器，因为故障转移无法自动执行。
在 Windows 上为 HA 部署 Always On 可用性组时需要 Windows Server 故障转移群集 (WSFC)。 给定可用性组的每个可用性副本必须位于相同 WSFC 的不同节点上。 唯一的例外是在迁移到另一个 WSFC 群集时，此时一个可用性组可能会暂时跨两个群集。
备注
有关 Linux 上可用性组的信息，请参阅 Linux 上的 SQL Server 的可用性组。
HA 配置中会为创建的每个可用性组创建一个群集角色。 WSFC 群集将监视此角色，以便评估主要副本的运行状况。 针对 Always On 可用性组的仲裁基于 WSFC 群集中的所有节点，而与给定群集节点是否托管任何可用性副本无关。 与数据库镜像相反，在 Always On 可用性组中没有见证服务器角色。
备注
有关 SQL Server Always On 组件与 WSFC 群集的关系的信息，请参阅 Windows Server 故障转移群集与 SQL Server。
下图显示的是一个包含一个主要副本和四个次要副本的可用性组。 支持最多八个次要副本，包括一个主要副本和四个同步提交次要副本。
术语和定义
展开表
| 术语 | 说明 |
|---|---|
| 可用性组 | 一个容器，用于一组共同实现故障转移的数据库（“可用性数据库”）。 |
| 可用性数据库 | 属于可用性组的数据库。 对于每个可用性数据库，可用性组将保留一个读写副本（“主数据库”）和一个到八个只读副本（“辅助数据库”）。 |
| 主数据库 | 可用性数据库的读写副本。 |
| 辅助数据库 | 可用性数据库的只读副本。 |
| 可用性副本 | 可用性组的实例化，该可用性组由特定的 SQL Server 实例承载，并维护属于该可用性组的每个可用性数据库的本地副本。 存在两种类型的可用性副本：一个主副本和一至八个辅助副本。 |
| 主要副本 | 使主数据库可用于来自客户端的读写连接并用于将每个主数据库的事务日志记录发送到每个辅助副本的可用性副本。 |
| 次要副本 | 维护各可用性数据库的辅助副本的可用性副本，充当可用性组的潜在故障转移目标。 或者，辅助副本可以支持对辅助数据库进行只读访问，并支持对辅助数据库创建备份。 |
| 可用性组侦听器 | 一个服务器名称，客户端可连接到此服务器以访问可用性组的主要副本或次要副本中的数据库。 可用性组侦听器将传入连接定向到主副本或只读辅助副本。 |
可用性数据库
若要将数据库添加到可用性组，该数据库必须是联机的读写数据库，它位于承载主副本的服务器实例上。 当您添加一个数据库时，它将作为主数据库加入可用性组，同时保持可用于客户端。 除非新的主数据库的备份还原到承载辅助副本（使用 RESTORE WITH NORECOVERY）的服务器实例，否则不存在对应的辅助数据库。 新的辅助数据库处于 RESTORING 状态，直至其加入可用性组。 有关详细信息，请参阅启动 AlwaysOn 辅助数据库的数据移动 (SQL Server)。
加入后，辅助数据库将进入 ONLINE 状态，并启动与对应主数据库之间的数据同步。 “数据同步”是在辅助数据库上重新生成对主数据库的更改的过程。 数据同步涉及主数据库将事务日志记录发送到辅助数据库。
重要
可用性数据库在 Transact-SQL、PowerShell 和 SQL Server 管理对象 (SMO) 名称中有时候被称作“数据库副本”。 例如，“数据库副本”一词用于返回与可用性数据库有关的信息的 AlwaysOn 动态管理视图的名称中：sys.dm_hadr_database_replica_states 和 sys.dm_hadr_database_replica_cluster_states。 但在 SQL Server 联机丛书中，“副本”一词通常表示可用性副本。 例如，“主副本”和“辅助副本”始终表示可用性副本。
可用性副本
每个可用性组定义一个包含两个或更多故障转移伙伴（称为可用性副本）的集合。 “可用性副本”是可用性组的组件。 每个可用性副本都承载可用性组中的可用性数据库的一个副本。 对于某个给定可用性组，可用性副本必须位于某一 WSFC 群集的不同节点上的单独 SQL Server 实例上。 必须为 AlwaysOn 启用这些服务器实例中的每个实例。
SQL Server 2019 (15.x) 将同步副本的最大数目从 SQL Server 2017 (14.x) 中的 3 增加到了 5。 可以配置此组的 5 个副本在该组中进行自动故障转移。 有 1 个主要副本以及 4 个同步的次要副本。
对于每个可用性组，一个给定实例只能承载一个可用性副本。 但是，每个实例可用于多个可用性组。 给定的实例可以是独立实例或 SQL Server 故障转移群集实例 (FCI)。 如果您要求服务器级别的冗余，则使用故障转移群集实例。
每个可用性副本都被分配一个初始角色（“主角色”或“辅助角色”），角色由该副本的可用性数据库继承。 给定副本的角色确定它承载的是读写数据库还是只读数据库。 其中一个副本（称为“主要副本”）被分配主角色，它承载读写数据库（称为“主数据库”）。 至少一个其他副本（称为“辅助副本”）被分配辅助角色。 辅助副本承载只读数据库（称为辅助数据库）。
备注
如果可用性副本的角色是不确定的（如在故障转移过程中），则其数据库将临时处于 NOT SYNCHRONIZING 状态。 其角色设置为 RESOLVING，直至可用性副本的角色已解析。 如果可用性副本解析为主角色，则其数据库将成为主数据库。 如果可用性副本解析为辅助角色，则其数据库将成为辅助数据库。
可用性模式
可用性模式是每个可用性副本的一个属性。 可用性模式确定主要副本是否在给定的次要副本将事务日志记录写入磁盘（强制写入日志）之前，等待提交数据库上的事务。 Always On 可用性组支持两种可用性模式：异步提交模式和同步提交模式。
- 异步提交模式使用此可用性模式的可用性副本称为“异步提交副本”。 在异步提交模式下，主要副本无需等待确认异步提交次要副本硬化事务日志，便可提交事务。 异步提交模式可最大限度地减少辅助数据库上的事务滞后时间，但允许它们滞后于主数据库，因此可能会导致某些数据丢失。
- 同步提交模式使用此可用性模式的可用性副本称为“同步提交副本”。 在同步提交模式下，在提交事务之前，同步提交主副本要等待同步提交辅助副本确认它已完成硬化日志。 同步提交模式可确保在给定的辅助数据库与主数据库同步时，充分保护已提交的事务。 这种保护的代价是延长事务滞后时间。 SQL Server 2017 选择性地引入了“要求同步的次要副本”功能，以便在需要时进一步提高安全性，但代价是延迟时间延长。 可以启用 REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT 功能，从而要求将指定数量的同步副本提交给事务后，才允许主要副本提交。
有关详细信息，请参阅 Always On 可用性组的可用性模式之间的差异。
故障转移类型
在主副本和辅助副本之间的对话上下文中，通过称为“故障转移”的过程，主角色和辅助角色是潜在可互换的。 在故障转移期间，目标次要副本转换为主角色，成为新的主要副本。 新的主副本使其数据库作为主数据库联机，而客户端应用程序可以连接到这些数据库。 如果以前的主副本可用，则它将转换为辅助角色，成为辅助副本。 以前的主数据库成为辅助数据库，且数据同步恢复。
可用性组在可用性副本级别进行故障转移。 故障转移不是由诸如因数据文件丢失而使数据库成为可疑数据库、删除数据库或事务日志损坏等此类数据库问题导致的。
有三种故障转移形式：自动、手动和强制（可能造成数据丢失）。 给定辅助副本支持的故障转移形式取决于其可用性模式，对于同步提交模式来说，取决于主副本和目标辅助副本的故障转移模式，如下所示。
- 同步提交模式支持两种故障转移形式：“计划的手动故障转移”和“自动故障转移”（如果目标次要副本当前与主副本同步）。 对这些故障转移形式的支持取决于故障转移伙伴上的“故障转移模式属性”的设置。 如果在主副本或辅助副本上将故障转移模式设置为“手动”，则对于该辅助副本仅支持手动故障转移。 如果同时在主副本和辅助副本上将故障转移模式设置为“自动”，则该辅助副本同时支持自动故障转移和手动故障转移。
- 计划的手动故障转移（无数据丢失）手动故障转移在数据库管理员发出故障转移命令之后发生，它将导致已同步的辅助副本转换为主角色（同时确保数据受到保护），而主副本转换为辅助角色。 手动故障转移要求主副本和目标辅助副本都在同步提交模式下运行，并且辅助副本必须已同步。
- 自动故障转移 （无数据丢失）自动故障转移是为了响应导致已同步的辅助副本转换为主角色（同时确保数据受到保护）的故障而执行的。 如果以前的主副本变为可用，则它将转换为辅助角色。 自动故障转移要求主要副本和目标次要副本都在同步提交模式下运行，并且故障转移模式设置为“自动”。 此外，次要副本必须已同步并具有 WSFC 仲裁，且满足由可用性组的灵活故障转移策略指定的条件。
- 在异步提交模式下，唯一的故障转移形式为强制手动故障转移（可能造成数据丢失），通常称作“强制故障转移”。 强制故障转移被认为是一种手动故障转移，因为它只能手动启动。 强制故障转移是一个灾难恢复选项。 当目标辅助副本与主副本不同步时，强制故障转移是唯一可能的故障转移形式。
有关详细信息，请参阅故障转移和故障转移模式（Always On 可用性组）。
重要
- SQL Server 故障转移群集实例 (FCI) 不支持通过可用性组来自动进行故障转移，因此，只能为手动故障转移配置任何由 FCI 承载的可用性副本。
- 如果对已同步的辅助副本发出强制故障转移命令，则辅助副本的行为与计划的手动故障转移时的行为相同。
好处
Always On 可用性组提供了一组丰富的选项来提高数据库的可用性并改进资源使用情况。 主要组件如下：
- 支持最多九个可用性副本。 “可用性副本”是可用性组的实例化，此可用性组由特定的 SQL Server 实例承载，该实例维护属于此可用性组的每个可用性数据库的本地副本。 每个可用性组都支持一个主副本和最多八个辅助副本。 有关详细信息，请参阅什么是 Always On 可用性组？
重要每个可用性副本都必须驻留在单个 Windows Server 故障转移群集 (WSFC) 群集的不同节点中。 有关可用性组的先决条件、限制和建议的详细信息，请参阅针对 Always On 可用性组的先决条件、限制和建议。 - 支持替代可用性模式，如下所示：
- 异步提交模式。 此可用性模式是一种灾难恢复解决方案，适合于可用性副本的分布距离较远的情况。
- 同步提交模式。 此可用性模式相对于性能而言更强调高可用性和数据保护，为此付出的代价是事务延迟时间增加。 一个给定的可用性组可支持最多 5 个同步提交可用性副本（包括当前主副本）。有关详细信息，请参阅 Always On 可用性组的可用性模式之间的差异。
- 支持几种形式的可用性组故障转移：自动故障转移、计划的手动故障转移（通常简称为“手动故障转移”）和强制的手动故障转移（通常简称为“强制故障转移”）。 有关详细信息，请参阅故障转移和故障转移模式（Always On 可用性组）。
- 使您能够将给定的可用性副本配置为支持以下一种或两种活动辅助功能：
- 利用只读连接访问，与副本的只读连接可以在此副本作为辅助副本运行时访问和读取其数据库。 有关详细信息，请参阅卸载对 AlwaysOn 可用性组的次要副本的只读工作负荷。
- 当副本作为辅助副本运行时，对副本的数据库执行备份操作。 有关详细信息，请参阅卸载可用性组次要副本的受支持备份。通过使用活动辅助功能，可以更好地利用辅助硬件资源，从而提高 IT 效率并降低成本。 此外，通过将读意向应用程序和备份作业转移到辅助副本，有助于提高针对主副本的性能。
- 支持每个可用性组的可用性组侦听器。 可用性组侦听程序是一个服务器名称，客户端可连接到此服务器以访问 Always On 可用性组的主要副本或次要副本中的数据库。 可用性组侦听器将传入连接定向到主副本或只读辅助副本。 侦听器在可用性组故障转移后提供快速应用程序故障转移。 有关详细信息，请参阅连接到 Always On 可用性组侦听器。
- 支持灵活的故障转移策略以便更好地控制可用性组故障转移。 有关详细信息，请参阅故障转移和故障转移模式（Always On 可用性组）。
- 支持用于避免页损坏的自动页修复。 有关详细信息，请参阅自动页修复（可用性组：数据库镜像）。
- 支持加密和压缩，这提供了安全且高性能的传输方式。
- 提供了一组集成的工具来简化部署和管理可用性组，这些工具包括：
- 用于创建和管理可用性组的 Transact-SQL DDL 语句。 有关详细信息，请参阅 Always On 可用性组的 Transact-SQL 语句。
- SQL Server Management Studio 工具，如下所示：
- 新建可用性组向导 创建和配置可用性组。 在某些环境中，此向导还可以自动准备辅助数据库并且为每个数据库启动数据同步。 有关详细信息，请参阅使用“新建可用性组”对话框 (SQL Server Management Studio)。
- 将数据库添加到可用性组向导 向现有可用性组添加一个或多个主数据库。 在某些环境中，此向导还可以自动准备辅助数据库并且为每个数据库启动数据同步。 有关详细信息，请参阅使用“可用性组向导”将数据库添加到 Always On 可用性组。
- 将副本添加到可用性组向导 向现有可用性组添加一个或多个辅助副本。 在某些环境中，此向导还可以自动准备辅助数据库并且为每个数据库启动数据同步。 有关详细信息，请参阅使用 SQL Server Management 中的可用性组向导将副本添加到 Always On 可用性组。
- 故障转移可用性组向导 启动对可用性组的手动故障转移。 根据您指定为故障转移目标的辅助副本的配置和状态，该向导可以指定计划的手动故障转移或强制手动故障转移。 有关详细信息，请参阅使用故障转移可用性组向导 (SQL Server Management Studio)。
- AlwaysOn 面板 监视 AlwaysOn 可用性组、可用性副本和可用性数据库，并且评估 AlwaysOn 策略的结果。 有关详细信息，请参阅使用 Always On 可用性组仪表板 (SQL Server Management Studio)。
- “对象资源管理器详细信息”窗格显示有关现有可用性组的基本信息。 有关详细信息，请参阅使用对象资源管理器详细信息监视可用性组。
- PowerShell cmdlet。 有关详细信息，请参阅 Always On 可用性组的 PowerShell Cmdlet 概述。
客户端连接
您可以通过创建一个可用性组侦听器来提供到给定可用性组的主副本的客户端连接。 “可用性组侦听器”提供一组附加到给定可用性组的资源，以便将客户端连接定向到相应的可用性副本。
一个可用性组侦听器与一个唯一的 DNS 名称（用作虚拟网络名称 (VNN)）、一个或多个虚拟 IP 地址 (VIP) 和一个 TCP 端口号关联。 有关详细信息，请参阅连接到 Always On 可用性组侦听器。
提示
如果一个可用性组仅拥有两个可用性副本，并且未配置为允许对次要副本进行读访问，则客户端可以通过使用数据库镜像连接字符串连接到主要副本。 从数据库镜像将数据库迁移到 AlwaysOn 可用性组之后，这种方法暂时非常有用。 在添加其他次要副本之前，需要为该可用性组创建一个可用性组侦听程序，并更新应用程序以使用该侦听程序的网络名称。
活动辅助副本
Always On 可用性组支持活动次要副本。 活动辅助功能包括对以下方面的支持：
- 对辅助副本执行备份操作次要副本支持对完整数据库、文件或文件组执行日志备份和仅复制备份。 您可以配置可用性组，以便为备份指定一个首选位置。 理解 SQL Server 不强制使用首选备份位置十分重要，因为它对即席备份没有影响。 对此首选备份位置的解释取决于为给定可用性组中的每个数据库撰写作业脚本的逻辑（如果有）。 对于单独的可用性副本，您可以指定对此副本（相对于同一可用性组中其他副本）执行备份的优先级。 有关详细信息，请参阅卸载可用性组次要副本的受支持备份。
- 对一个或多个辅助副本（可读辅助副本）的只读访问权限可以对任何次要可用性副本进行配置，以便仅允许对其本地数据库进行只读访问，尽管不会完全支持某些操作。 这会阻止对次要副本进行读写连接尝试。 还可以通过仅允许进行读写访问来阻止主要副本上的只读工作负载。 这会阻止对主要副本建立只读连接。 有关详细信息，请参阅卸载对 AlwaysOn 可用性组的次要副本的只读工作负荷。如果某一可用性组当前拥有一个可用性组侦听程序以及一个或多个可读次要副本，则 SQL Server 可以将读意向连接请求路由到其中一个可读次要副本（只读路由）。 有关详细信息，请参阅连接到 Always On 可用性组侦听器。
会话超时期限
会话超时期限是一个可用性副本属性，它决定在连接关闭前与另一个可用性副本的连接可处于不活动状态多长时间。 主要副本和次要副本相互 ping 以表示它们还处于活动状态。 如果在超时期限内从其他副本收到 ping，则表示连接仍是打开的，且服务器实例正在进行通信。 收到 ping 后，可用性副本将重置此连接的会话超时计数器。
会话超时期限防止副本无限制等待接收来自另一个副本的 ping。 如果在会话超时期限内没有收到来自另一个副本的 ping，该副本将超时。连接将关闭，超时的副本进入 DISCONNECTED 状态。 即使为同步提交模式配置了断开连接的副本，事务也不会等待该副本重新连接和重新同步。
每个可用性副本的默认会话超时期限为 10 秒。 用户可配置此值，最小值为 5 秒。 通常我们建议您将超时期限保持为 10 秒或更长。 如果将值设置为低于 10 秒，则可能使高负荷系统声明虚假故障。
备注
在“正在解析”角色中，会话超时期限不适用，因为不进行 ping。
自动页修复
每个可用性副本都通过解决阻止读取数据页的一定类型的错误，自动尝试从本地数据库上损坏的页中恢复。 如果次要副本无法读取某页，则该副本从主副本请求该页的新副本。 如果主副本无法读取某页，该副本将向所有辅助副本广播索取新副本的请求，并从响应的第一个副本中获取该页。 如果此请求成功，则将以新副本替换不可读的页，这通常会解决该错误。
有关详细信息，请参阅自动页修复（可用性组：数据库镜像）。