SQL Server Always On 可用性组：完整指南 [2026]

1. 了解 Always On 可用性组

1.1 它是什么以及它是如何工作的

Always On 可用性组 (AG) 是一种 SQL Server 企业版 高可用性 这是一种在数据库级别运行的灾难恢复解决方案。可用性组将一个或多个用户数据库组合成一个故障转移单元，并通过连续事务日志传送将其复制到最多八个辅助副本。当主副本发生故障时，指定的同步辅助副本会自动接管，无需共享存储或人工干预，即可在几秒钟内恢复访问。

1.2 Always On 可用性组与故障转移群集实例

SQL Server Always On 包含两种不同的技术：可用性组 (AG) 和故障转移群集实例 (FCI)：

	Always On 可用性组	Always On 故障转移集群实例
故障转移范围	数据库级	实例级（所有数据库同时故障转移）
数据复制	基于日志的复制到每个辅助节点	无 — 所有节点共享同一存储空间
共享存储	不需要	必需（存储区域网络 (SAN)、iSCSI、S2D 或 SMB）
可读的二级	是	没有
灾难恢复	内置（跨站点异步副本）	不与 AG 配对则无法内置。

何时使用： 当您需要实例级故障转移且已拥有共享存储基础架构时，请使用 FCI。当您需要数据库级粒度控制、可读辅助副本或灾难恢复时，请使用 AG。为了获得最全面的保护，请将两者结合使用：将每个副本作为 FCI 节点运行，并将它们链接到 AG 中。

1.3 优点和局限性

产品优势

• 同步副本自动故障转移，恢复时间目标 (RTO) 接近于零；
• 同步提交模式下零数据丢失（恢复点目标 (RPO) = 0）；
• 无需共享存储——每个副本都使用独立的本地存储；
• 可读的辅助存储设备可以减轻主存储设备的报表和备份工作负载；
• 在单一配置中同时支持本地高可用性 (HA) 和跨站点灾难恢复 (DR)。

限制：

• 需要在所有副本上启用 Windows Server 故障转移群集；
• 企业版提供完整功能集（标准版支持基本 AG，但有诸多限制）；
• 同步提交模式会增加写入操作的延迟，延迟时间与网络往返时间成正比；
• 登录信息、SQL Agent 作业和链接服务器不会自动同步。 SQL Server 2019 年及更早（已解决） SQL Server 2022 年包含可用性组）。

2. Always On 可用性组架构

2.1 核心组成部分和概念

2.1.1 可用性数据库

可用性数据库是参与可用性组的用户数据库。这些数据库必须满足特定要求：它们必须使用完整恢复模式，拥有完整备份，并且在添加到可用性组之前必须存在于主副本上。

当数据库加入可用性组时，它就成为一个同步集合的一部分，该集合可以作为一个整体进行故障转移。可用性组中的所有数据库共享相同的故障转移状态，这意味着如果主副本发生故障，所有数据库将同时故障转移到同一个辅助副本。这确保了依赖多个相关数据库的应用程序的一致性。

2.1.2 可用性副本

可用性副本是 SQL Server 可用性组是托管可用性数据库副本的实例。每个副本都维护着自己的数据库物理副本，并通过事务日志记录传送进行同步。一个可用性组最多可以包含九个副本：一个主副本和最多八个辅助副本。

2.1.3 主副本

主副本托管可用性数据库的读写副本。所有数据修改（INSERT、UPDATE、DELETE）都在主副本上进行。客户端应用程序连接到主副本以执行所有写入操作，默认情况下，读取操作也连接到主副本。

2.1.4 二级副本

辅助副本托管可用性数据库的只读副本，这些副本通过持续应用从主副本接收的事务日志记录来维护。每个辅助副本接收、强化并应用日志记录，以保持其数据库副本与主数据库同步。

2.2 可用性模式

2.2.1 同步提交模式

同步提交模式通过要求主副本在提交事务之前等待辅助副本确认事务日志记录已加固，从而提供零数据丢失保护。此模式对于数据丢失不可接受的高可用性配置至关重要。

2.2.2 异步提交模式

异步提交模式优先考虑主副本的性能，允许事务在无需等待辅助副本确认日志加固的情况下提交。此模式适用于灾难恢复副本，或当网络延迟导致同步提交不切实际时。

这种方式的弊端在于故障转移期间可能存在数据丢失。如果主副本发生故障，某些已提交的事务可能无法到达备用副本。潜在的数据丢失量取决于网络带宽、备用副本性能以及故障发生的时间。组织在使用异步模式时必须接受这种风险。

2.3 故障转移类型

2.3.1 自动故障转移

自动故障转移功能使可用性组能够检测主副本故障，并在无需管理员干预的情况下自动将辅助副本提升为主副本。此功能消除了对故障进行手动响应的需求，从而最大限度地缩短了恢复时间目标 (RTO)。

自动故障转移需要同步提交模式以确保零数据丢失。启用后，可用性组会持续监控主副本的运行状况。如果主副本无响应或发生故障，Windows Server 故障转移群集将自动故障转移到指定的辅助副本。

2.3.2 手动故障转移

手动故障转移允许管理员有意地将主副本角色切换到辅助副本，通常用于计划内维护或测试。与自动故障转移不同，手动故障转移需要管理员明确执行操作才能启动。

对于同步提交副本，支持无数据丢失的手动故障转移。管理员通过以下方式发起故障转移： SQL Server 可以使用 Management Studio、Transact-SQL 或 PowerShell。主副本完成当前事务的处理后，会将所有剩余的日志记录发送到目标辅助副本，并等待确认后才会转移主角色。

异步提交副本也可以进行手动故障转移，但这需要强制故障转移，可能会导致数据丢失。管理员仅应在实际灾难情况下，即主副本不可用且数据丢失与长时间停机相比可以接受时，才使用强制手动故障转移。

2.3.3 强制故障转移

强制故障转移允许故障转移到异步辅助副本或未完全同步的辅助副本，但会明确告知用户可能存在数据丢失。此选项作为最后的手段，用于主副本不可用且不存在同步的辅助副本的情况。

2.4数据同步

2.4.1 数据同步的工作原理

Always On 可用性组的数据同步是通过将事务日志记录从主副本持续传输到所有辅助副本来实现的。这种基于日志的同步方式既保证了数据的一致性，又允许每个副本拥有独立的存储空间。

2.4.2 事务日志记录和加固

事务日志加固是关键步骤，它将日志记录写入辅助副本上的持久存储。加固可确保日志记录在辅助副本发生故障时仍然存在，并可在恢复期间重放。

2.5 读取规模和可读取的二级副本

2.5.1 卸载只读工作负载

可读辅助副本使组织能够将读取密集型工作负载从主副本卸载，从而提高整体系统性能和资源利用率。这种读取扩展能力是可用性组相对于旧式高可用性解决方案的关键优势之一。

组织在设计可用性组配置时应考虑只读工作负载需求。多个可读辅助服务器可以将报告负载分散到多个服务器上。只读路由列表定义了辅助服务器接收读取意图连接的顺序，从而实现负载均衡策略。

2.5.2 辅助副本上的备份操作

在辅助副本上运行备份可以降低主副本的输入/输出 (I/O) 和中央处理器 (CPU) 负载，使其能够专注于事务性工作负载。此功能有助于组织在不影响生产性能的前提下满足备份需求。

SQL Server 支持在辅助副本上进行完整数据库备份、差异备份和事务日志备份。备份首选项可以配置为优先使用辅助副本、优先使用主副本、仅使用辅助副本或使用任意副本。备份系统会根据这些首选项和当前可用性自动选择合适的副本。

有关详细信息 SQL Server 备份，请参阅我们的 综合指南.

2.6 可用性组监听器

2.6.1 什么是监听器？

可用性组侦听器是一个虚拟网络名称 (VNN) 和 IP 地址，客户端应用程序使用它来连接到可用性组数据库。侦听器会自动将连接重定向到当前主副本，从而无需应用程序跟踪哪个服务器当前是主服务器。

2.6.2 客户端连接路由

客户端连接路由通过监听器支持读写和只读连接意图。监听器会检查连接请求，并根据应用程序的意图将其路由到相应的副本。

3. 先决条件和要求

3.1 Windows Server 可用性组的故障转移群集

3.1.1 Windows Server故障转移群集基础知识

Windows Server故障转移群集 (WSFC) 通过管理群集成员、运行状况监视和故障转移编排，为 Always On 可用性组奠定了基础。与故障转移群集实例不同，可用性组仅使用 WSFC 进行群集协调，而不用于共享存储管理。

每 SQL Server 参与可用性组的实例必须是 WSFC 集群中的一个节点。集群负责管理仲裁投票、节点健康检测和可用性组资源状态。当主副本发生故障时，WSFC 会协调故障转移过程，并更新集群资源以反映新的主副本。

3.1.2 集群仲裁配置

集群法定人数决定了网络连接出现问题时哪些节点可以运行，从而防止出现多个节点各自独立声称自己是主节点的脑裂情况。法定人数配置定义了集群决策中多数投票的条件。

可用性组有多种法定人数模式可供选择：

• 节点多数制仅使用集群节点投票，并且适用于节点数为奇数的集群。
• 节点和文件共享多数投票功能增加了一个文件共享见证投票，适用于偶数节点集群。
• 节点和磁盘多数模式使用磁盘见证，但对于可用性组来说不太常见，因为不需要共享存储。

3.1.3 多子网聚类

多子网集群使可用性组副本能够跨越不同的网络子网，从而支持跨数据中心的地理分布式部署。对于副本位于不同位置的灾难恢复配置而言，此功能至关重要。

3.2 SQL Server 版本要求

3.2.1 企业版功能

SQL Server 企业版提供完整的可用性组功能，没有任何限制。企业版支持最多八个辅助副本、可读辅助副本、自动种子数据、分布式可用性组以及所有高级功能。

3.2.2 标准版功能（基本可用性组）

SQL Server 2016 标准版及更高版本对基本可用性组的支持存在诸多限制。基本可用性组以较低的成本提供核心高可用性功能，适用于需求较为简单的组织。

4. 配置 Always On 可用性组

4.1 环境准备

在创建可用性组之前，必须正确准备环境，包括 Active Directory 帐户、服务器配置和网络基础设施。

4.1.1 域控制器设置

必须配置 Active Directory 域控制器以支持可用性组群集，并且 SQL Server 服务帐户。

1. 使用域管理员凭据登录域控制器。
2. 可选 服务器管理器 并导航到 工具 -> 活动目录用户和计算机.
3. 创建一个组织单元 SQL Server 如果对象不存在，则不创建对象。
4. 确认所有集群节点的计算机对象都存在于 Active Directory 中。
5. 确保域名系统（DNS）服务配置正确，并且所有服务器名称都能正确解析。

4.1.2 创建服务帐户

创建专用的 Active Directory 服务帐户 SQL Server 每个节点上的服务。

1. 可选 活动目录用户和计算机 在域控制器上。
2. 右键单击相应的组织单元并选择 全新发布 -> 用户.
3. 输入服务帐户名称（例如，svc_SQLServer）并进行设置 用户登录名.
4. 点击 下一篇 并输入一个强密码。
5. 选择 用户无法更改密码 和 密码永不过期.
6. 点击 下一篇 然后 完成 创建帐户。
7. 重复以上步骤，直至获得所需的其他服务帐户（SQL Server 代理、SSRS 等）。

4.1.3 配置管理员权限

服务帐户和用于配置的帐户 SQL Server 必须拥有对所有集群节点的相应权限。

1. 登录到每个集群节点服务器。
2. 可选 计算机管理 来自 开始 菜单或服务器管理器。
3. 拓展 本地用户和组 并选择 群.
4. 右键单击 管理人员 并选择 物业.
5. 点击 添加 然后输入服务帐户名称。
6. 点击 检查名称 验证帐户，然后单击 OK.
7. 点击 OK 关闭“管理员属性”对话框。
8. 在所有集群节点上重复上述步骤。

4.2 安装和配置 WSFC

在启用 Always On 可用性组之前，必须先在所有节点上安装和配置 Windows Server 故障转移群集。

4.2.1 安装故障转移群集功能

在将要加入可用性组的每台服务器上安装故障转移群集功能。

1. 可选 服务器管理器 在第一个集群节点上。
2. 点击 物业管理 -> 添加角色和功能.
3. 点击 下一篇 通过介绍屏幕。
4. 选择 基于角色或基于功能的安装 并点击 下一篇.
5. 选择本地服务器并单击 下一篇.
6. 跳过“角色”屏幕并单击 下一篇.
7. 在“功能”屏幕上，选择 故障转移群集.
8. 点击 添加功能 当被要求添加管理工具时。
9. 点击 下一篇 然后 安装.
10. 等待安装完成并点击 关闭.
11. 对集群中所有服务器重复上述步骤。

4.2.2 创建故障转移群集

在所有节点上安装故障转移集群功能后，从其中一个节点创建集群。

1. 可选 故障转移集群管理器 ，来自 服务器管理器 -> 工具.
2. 点击 创建集群 在“操作”窗格中。
3. 点击 下一篇 在“开始之前”页面上。
4. 点击 浏览 添加所有将作为集群节点的服务器。
5. 点击 下一篇 添加完所有节点后。
6. 离开 运行所有测试（推荐） 选中并点击 下一篇.
7. 审查验证测试结果，并处理任何错误或警告。
8. 点击 完成 验证成功完成后。
9. 请输入集群名称和 IP 地址。
10. 取消选中 将所有符合条件的存储设备添加到集群中。 因为不需要共享存储。
11. 点击 下一篇 并查看确认信息。
12. 点击 完成 创建集群。

4.2.3 验证集群配置

验证集群配置，确保所有节点都能正常通信，并且集群运行正常。

1. In 故障转移集群管理器右键单击集群名称。
2. 选择 验证集群 从菜单。
3. 点击 下一篇 在“开始之前”页面上。
4. 选择 运行所有测试（推荐） 并点击 下一篇.
5. 点击 下一篇 开始验证测试。
6. 测试完成后，请查看验证报告。
7. 解决报告中指出的所有故障或警告。
8. 点击 完成 关闭向导。

切勿安装 SQL Server 可用性组

安装 SQL Server 在每个将参与可用性组的节点上使用独立安装选项。

1. 运行 SQL Server 在第一个节点上安装介质。
2. 选择 全新发布 SQL Server 独立安装.
3. 输入产品密钥或选择评估版。
4. 接受许可条款并点击 下一篇.
5. 完成所有必要检查并解决任何问题。
6. 在“功能选择”页面上，选择 数据库引擎服务.
7. 配置实例名称（在所有节点上使用相同的实例名称）。
8. 在服务器配置页面上，指定服务帐户凭据。
9. 配置服务启动类型为 自动表.
10. 在数据库引擎配置页面上，选择身份验证模式。
11. 添加管理员帐户。
12. 配置数据目录，使其在所有节点上保持一致的路径。
13. 完成安装并验证是否成功。
14. 使用相同的设置对集群中的所有其他节点重复安装。

4.4 启用 Always On 可用性组功能

安装后 SQL Server 在所有节点上，为每个实例启用 Always On 可用性组功能。

4.4.1 通过以下方式启用 SQL Server 配置管理器

绝大部分储备使用 SQL Server 通过图形界面使用配置管理器启用 Always On 可用性组。

1. 可选 SQL Server 配置管理器 在第一个节点上。
2. 拓展 SQL Server 服务范围 在左侧窗格中。
3. 用鼠标右键单击 SQL Server 实例并选择 物业.
4. 点击 AlwaysOn 高可用性 标签。
5. 确保 启用 AlwaysOn 可用性组.
6. 请确认Windows故障转移群集名称是否正确。
7. 点击 OK 保存更改。
8. 点击 OK 收到服务必须重启的警告。
9. 用鼠标右键单击 SQL Server 服务并选择 重新启动.
10. 等待服务成功重启。
11. 在所有集群节点上重复上述步骤。

4.4.2 通过 PowerShell 启用

PowerShell 提供了一种脚本方法来跨多个节点启用 Always On 可用性组。

1. 在第一个节点上以管理员身份打开 PowerShell。
2. 导入 SQL Server PowerShell 模块：

   Import-Module SQLPS -DisableNameChecking

3. 启用 Always On 可用性组：

   Enable-SqlAlwaysOn -ServerInstance "ServerName\InstanceName" -Force

4. 使用 Force 参数时，服务将自动重启。
5. 请确认该功能已启用：

   Get-ItemProperty "SQLSERVER:\SQL\ServerName\InstanceName" | Select-Object IsHadrEnabled

6. 对每个集群节点重复上述步骤，替换为相应的服务器和实例名称。

4.4.3 验证功能是否已启用

在继续配置之前，请确认所有实例上都已启用 Always On 可用性组。

1. 连接到每个 SQL Server 使用实例 SQL Server 管理工作室。
2. 打开一个新的查询窗口并执行：

   SELECT SERVERPROPERTY('IsHadrEnabled')

3. 确认结果为 1（已启用）。
4. 检查一下 SQL Server 实例出现在故障转移集群管理器中的集群角色下。
5. 通过执行以下命令验证可用性组端点是否存在：

   SELECT * FROM sys.endpoints WHERE type_desc = 'DATABASE_MIRRORING'

6. 如果端点不存在，则会在创建可用性组期间创建该端点。

4.5 为可用性组准备数据库

数据库必须满足特定要求才能添加到可用性组中。

4.5.1 数据库恢复模型要求

在将主副本添加到可用性组之前，请将其数据库恢复模式更改为 FULL。

1. 使用以下方式连接到主副本 SQL Server 管理工作室。
2. 右键单击数据库并选择 物业.
3. 点击 可选项 页面。
4. 更改 恢复模式 至 全.
5. 点击 OK 以保存更改。
6. 或者，使用 Transact-SQL：

   ALTER DATABASE DatabaseName SET RECOVERY FULL;

4.5.2 执行完整数据库备份

对数据库进行完整备份，以建立可用性组所需的备份链。

1. In SQL Server 在 Management Studio 中，右键单击数据库。
2. 选择 任务 -> 备份.
3. 确认 备份类型 被设置为 全.
4. 选择备份目标位置或添加新目标位置。
5. 点击 OK 执行备份。
6. 或者，使用 Transact-SQL：

   BACKUP DATABASE DatabaseName TO DISK = 'C:\Backup\DatabaseName.bak';

4.5.3 进行事务日志备份

进行事务日志备份，以确保日志链已建立，并最大限度地缩短初始化时间。

1. In SQL Server 在 Management Studio 中，右键单击数据库。
2. 选择 任务 -> 备份.
3. 更改 备份类型 至 事务日志.
4. 选择备份目标位置。
5. 点击 OK 执行备份。
6. 或者，使用 Transact-SQL：

   BACKUP LOG DatabaseName TO DISK = 'C:\Backup\DatabaseName.trn';

4.6 创建可用性组

根据您的偏好和自动化要求，可以使用几种可用方法之一创建可用性组。

4.6.1 使用新建可用性组向导

新建可用性组向导提供了一个用于创建可用性组的图形界面。

1. In SQL Server Management Studio，连接到将托管主副本的实例。
2. 拓展 AlwaysOn 高可用性 在对象资源管理器中。
3. 右键单击 可用性组 并选择 新建可用性组向导.
   
4. 点击 下一篇 在简介页。
5. 输入可用性组的名称，然后单击 下一篇.
6. 在“选择数据库”页面上，选择要包含的数据库。
7. 确认数据库满足所有先决条件，然后单击 下一篇.
8. 在“指定副本”页面上，单击 添加副本.
9. 连接到每个辅助副本实例。
10. 为每个实例配置副本属性（可用性模式、故障转移模式）。
11. 点击 端点 切换到选项卡并查看端点配置。
12. 点击 备份偏好设置 切换到“备份优先级”选项卡并配置备份优先级。
13. 点击 倾听者 按下选项卡，并可选择创建监听器。
14. 点击 下一篇 并选择数据同步方法。
15. 审查验证结果并解决任何问题。
16. 点击 下一篇 并审阅摘要。
17. 点击 完成 创建可用性组。
18. 监控进度并验证创建是否成功。

4.6.2 使用 Transact-SQL

使用 Transact-SQL 创建可用性组，实现可脚本化、可重复的部署。

1. 在主副本上创建可用性组：

   CREATE AVAILABILITY GROUP AG_Name
   FOR DATABASE DatabaseName
   REPLICA ON
     'PrimaryServer\Instance' WITH
       (ENDPOINT_URL = 'TCP://PrimaryServer:5022',
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
        FAILOVER_MODE = AUTOMATIC,
        SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL)),
     'SecondaryServer\Instance' WITH
       (ENDPOINT_URL = 'TCP://SecondaryServer:5022',
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
        FAILOVER_MODE = AUTOMATIC,
        SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL));

2. 将辅助副本加入可用性组：

   ALTER AVAILABILITY GROUP AG_Name JOIN;

3. 加入辅助数据库：

   ALTER DATABASE DatabaseName SET HADR AVAILABILITY GROUP = AG_Name;

4.6.3 使用 PowerShell

PowerShell 提供用于创建和管理可用性组的脚本功能。

1. 创建可用性组对象：

   $AG = New-SqlAvailabilityGroup -Name "AG_Name" -Path "SQLSERVER:\SQL\PrimaryServer\Instance"

2. 添加数据库：

   Add-SqlAvailabilityDatabase -Path "SQLSERVER:\SQL\PrimaryServer\Instance\AvailabilityGroups\AG_Name" -Database "DatabaseName"

3. 使用 New-SqlAvailabilityReplica cmdlet 配置具有所需属性的副本。
4. 使用 Join-SqlAvailabilityGroup cmdlet 连接辅助副本。

4.7 向可用性组添加副本

配置副本特定属性，以控制每个实例如何参与可用性组。

4.7.1 配置副本属性

为每个副本设置属性，以定义其在可用性组中的角色和功能。

1. In SQL Server 管理工作室，扩展 AlwaysOn 高可用性 -> 可用性组.
2. 展开可用性组，然后展开 可用性副本.
   
3. 右键单击副本并选择 物业.
4. 检查并修改主角色和辅助角色的连接设置。
5. 如有需要，请配置会话超时值。
6. 点击 OK 保存更改。

4.7.2 设置可用性模式

配置可用性模式以控制副本之间的同步行为。

1. 右键单击可用性组并选择 物业.
2. 在 General (将军) 页面，转到 可用性副本 部分。
3. 对于每个副本，选择 同步提交 or 异步提交 从下拉列表。
4. 对本地高可用性副本使用同步提交。
5. 对地理位置分散的灾难恢复副本使用异步提交。
6. 点击 OK 以保存配置。

4.7.3 设置故障转移模式

配置故障转移模式，以控制每个副本的故障转移方式。

1. 右键单击可用性组并选择 物业.
2. 在 General (将军) 页面，转到 可用性副本 部分。
3. 对于同步提交副本，请选择 自动表 or 用户手册 故障转移模式。
4. 自动故障转移需要同步提交模式，并支持无人值守故障转移。
5. 对于异步提交副本，仅支持手动故障转移。
6. 最多可配置三个副本以实现自动故障转移（一个主副本和两个辅助副本）。
7. 点击 OK 应用设置。

4.7.4 配置备份首选项

设置备份首选项以控制备份操作的执行位置。

1. 右键单击可用性组并选择 物业.
2. 选择 备份偏好设置 在左侧窗格中。
3. 选择以下备份首选项之一：
   • 优先考虑次要因素：如果备用备份可用，则备份到备用备份盘；否则备份到主备份盘。
   • 仅中学仅在辅助副本上进行备份
   • 主仅在主副本上进行备份
   • 任何复制品：在任何可用副本上进行备份
4. 为每个副本设置备份优先级值（0-100）。
5. 优先级越高，表示首选备份目标。
6. 点击 OK 保存设置。

4.8 配置可用性组侦听器

创建一个监听器，提供一个单一的连接点，该连接点会自动重定向到当前主副本。

4.8.1 创建监听器

为可用性组添加客户端连接管理监听器。

1. In SQL Server Management Studio，展开可用性组。
2. 右键单击 可用性组监听器 并选择 添加监听器.
   
3. 输入监听器的 DNS 名称（例如，AG_Listener）。
4. 输入端口号（默认值为 1433）。
5. 选择 静态IP 用于网络模式。
6. 点击 添加 为每个子网添加一个IP地址。
7. 输入IP地址并选择子网。
8. 点击 OK 创建监听器。
9. 确认监听器出现在对象资源管理器中且处于联机状态。

4.8.2 配置 DNS 和 IP 设置

请验证监听器的 DNS 注册和网络配置。

1. 在域控制器上打开DNS管理器。
2. 确认监听器名称已注册到所有 IP 地址。
3. 从客户端计算机测试 DNS 解析：

   nslookup ListenerName

4. 确认所有已配置的IP地址均已返回。
5. 在故障转移集群管理器中，展开 角色 并选择可用性组。
6. 请确认IP地址资源是否在线。
7. 检查网络名称资源是否在线。
   

4.8.3 测试监听器连接性

验证客户端应用程序是否可以通过监听器连接。

1. 从客户端计算机打开 SQL Server 管理工作室。
2. 使用监听器名称而不是服务器名称进行连接。
3. 执行查询以验证与当前主副本的连接：

   SELECT @@SERVERNAME;

4. 通过在连接字符串中添加 ApplicationIntent=ReadOnly 来测试读取意图路由。
5. 验证连接是否重定向到可读的辅助副本。
6. 手动将可用性组切换到故障转移状态并验证重新连接，以此测试故障转移功能。

4.9 数据同步方法

选择一种数据同步方法来初始化数据库副本的辅助副本。

4.9.1 自动播种

自动种子数据通过网络传输数据库数据，无需手动备份和恢复。

1. 在创建可用性组期间，选择 自动播种 作为同步方法。
   
2. 确保副本之间的网络连接和足够的带宽。
3. 主副本会自动将数据库数据流式传输到辅助副本。
4. 使用可用性组仪表板或 DMV 监控种子部署进度。
5. 自动播种需要 SQL Server 2016或更高版本。
6. 对于大型数据库，应考虑网络影响，并在低使用时段进行调度。

4.9.2 手动播种（备份和恢复）

手动备份是指在主服务器上进行备份，然后将备份恢复到辅助副本上。

1. 在主副本上，进行完整备份：

   BACKUP DATABASE DatabaseName TO DISK = '\\SharePath\DatabaseName.bak';

2. 备份交易日志：

   BACKUP LOG DatabaseName TO DISK = '\\SharePath\DatabaseName.trn';

3. 在每个辅助副本上，恢复完整备份：

   RESTORE DATABASE DatabaseName FROM DISK = '\\SharePath\DatabaseName.bak' WITH NORECOVERY;

4. 恢复日志备份：

   RESTORE LOG DatabaseName FROM DISK = '\\SharePath\DatabaseName.trn' WITH NORECOVERY;

5. 将数据库加入可用性组：

   ALTER DATABASE DatabaseName SET HADR AVAILABILITY GROUP = AG_Name;

6. 验证同步开始，数据库达到 SYNCHRONIZED 状态。

4.9.3 数据库快照文件

使用数据库快照文件从现有数据库文件初始化辅助副本。

1. 从主副本上分离或备份数据库。
2. 使用相同的文件路径将数据库文件复制到每个辅助副本。
3. 在辅助副本上，附加数据库或恢复数据库而不进行恢复。
4. 确保数据库处于恢复状态。
5. 将数据库加入可用性组。
6. 这种方法适用于网络传输不切实际的大型数据库。

5。 常问问题

5.1 一般问题

问：Always On FCI 和 Always On AG 有什么区别？

答：Always On 故障转移集群实例使用共享存储提供实例级高可用性，而 Always On 可用性组不使用共享存储提供数据库级高可用性。可用性组提供可读辅助数据库和更灵活的地理分布。

问：我可以将 Always On 可用性组与以下情况一起使用： SQL Server 标准版？

答：是的， SQL Server 2016 标准版及更高版本支持基本可用性组，但存在一些限制，包括每个可用性组只能有一个数据库、最多两个副本，并且不支持可读辅助数据库。

问：Always On可用性组需要共享存储吗？

答：不，可用性组不需要共享存储。每个副本都在本地存储上维护独立的数据库副本，并通过事务日志传送进行同步。

问：可用性组中最多可以有多少个副本？

A: SQL Server 企业版最多支持九个副本（一个主副本和八个辅助副本）。分布式可用性组最多可支持两个可用性组共 18 个副本。

5.2 配置问题

问：如何选择同步提交模式还是异步提交模式？

答：对于同一数据中心或低延迟网络中零数据丢失要求，请使用同步提交。对于远程灾难恢复副本，如果同步提交会影响性能，请使用异步提交。

问：我可以在同一个可用性组中混合使用同步副本和异步副本吗？

答：是的，可用性组支持同步副本和异步副本的混合配置。这使得同步副本能够实现本地高可用性，异步副本能够实现远程灾难恢复。

问：故障转移期间我的连接会发生什么情况？

答：发生故障转移时，现有连接将被断开。具有连接重试逻辑的应用程序会自动通过监听器重新连接到新的主节点。故障转移过程通常会在几秒到几分钟内完成。

问：我是否需要跨副本同步登录信息和作业？

答：在 SQL Server 2019 年及更早版本，是的——登录名、SQL Agent 作业和链接服务器必须手动同步。 SQL Server 2022 年引入了包含可用性组，这些对象会自动包含在内。

5.3 管理问题

问：我可以在辅助副本上运行备份吗？

答：是的，辅助副本支持完整备份、差异备份和事务日志备份。配置备份首选项，将备份任务从主副本卸载，从而降低其资源占用。

问：如何打补丁？ SQL Server 尽量减少停机时间？

答：采用滚动升级的方式，先修补辅助副本，然后手动故障转移到已修补的辅助副本，最后修补原主副本。这样可以将停机时间控制在故障转移期间。

问：我可以将数据库添加到现有的可用性组中吗？

答：是的，数据库可以添加到正在运行的可用性组中。数据库必须处于完整恢复模式并拥有完整备份，辅助副本必须使用自动初始化或手动备份和恢复进行初始化。

问：什么是自动播种？我应该使用它吗？

答：自动初始化是指通过网络传输数据库数据来初始化辅助副本，无需手动备份。适用于小型数据库或网络带宽充足的情况。对于非常大的数据库，手动初始化可能更快。

问：在可用性组中，我应该在哪里运行 DBCC CHECKDB？

答：您应该在辅助副本上运行 DBCC CHECKDB，以减轻主副本的负载。数据库一致性检查可以在不影响主副本性能的情况下对辅助数据库执行。

有关 DBCC CHECKDB 的更多详细信息，请参阅我们的 综合指南.

5.4 故障排除问题

问：为什么我的数据库处于“未同步”状态？

答：常见原因包括网络连接问题、数据传输暂停、辅助副本磁盘空间不足或终端问题。请检查同步运行状况描述和 SQL Server 错误日志包含具体详细信息。如果辅助数据库已进入错误日志，则需要查看辅助数据库的错误日志。 恢复状态 或显示 待恢复请参阅相关指南以获取针对性修复方法。

问：当主服务器不可用时，如何强制进行故障转移？

答：连接到辅助副本并执行 ALTER AVAILABILITY GROUP AG_Name FORCE_FAILOVER_ALLOW_DATA_LOSS 命令。此操作会确认潜在的数据丢失，并将辅助副本立即提升为主副本。

问：为什么客户端无法连接到我的监听器？

A：在故障转移集群管理器中验证监听器是否在线，DNS 注册是否成功，所有监听器 IP 是否可从客户端访问，以及防火墙规则是否允许流量流向监听器端口。

问：大型重做队列意味着什么？

答：过大的重做队列表明辅助副本无法及时应用到达的日志记录。这可能表明磁盘 I/O 瓶颈、CPU 限制或辅助副本上的只读查询阻塞。

问：如果灾难影响到所有副本，并且我的备份也损坏了，我该怎么办？

答：虽然这种情况极其罕见，但勒索软件攻击、大范围存储故障或连锁灾难都可能导致这种最糟糕的情况发生。您的首要防御措施是预防：维护地理位置分散的副本，将备份存储在不同的位置，以及
定期测试您的灾难恢复流程。如果所有标准恢复选项都失败，则需要专门的灾难恢复方案。 SQL 数据恢复工具 可以尝试从损坏的 MDF 文件中提取数据，作为紧急的最后手段。

5.5 许可和费用问题

问：Always On 可用性组的许可方式是什么？

A: SQL Server 许可取决于版本和部署模型。企业版可用性组要求所有副本都拥有企业版许可证。被动辅助副本在特定条件下可能符合免费许可条件。

问：可以用吗 SQL Server 面向可用性组的开发者版本？

答：是的，开发者版包含企业版的所有功能，包括完整的可用性组支持。但是，它仅授权用于开发和测试，不得用于生产环境。

问：可读二级文档是否需要额外许可证？

答：许可取决于具体应用场景。用于灾难恢复的被动式辅助服务器通常不需要许可。服务于只读工作负载的主动式辅助服务器通常需要许可，但具体条款可能有所不同。

问：有没有免费的方法可以实现高可用性？ SQL Server?

A: SQL Server Express Edition 不支持可用性组。 SQL Server 标准版支持从以下版本开始的基本可用性组： SQL Server 2016 年，以标准版许可费用提供基本的高可用性。

问：什么是分布式可用性组？

答：分布式可用性组是一种特殊的可用性组，它跨越两个独立的可用性组，能够实现传统可用性组无法胜任的场景。它于[此处应填写引入日期]被引入。 SQL Server 2016 年，分布式可用性组解决了扩展性和地理分布要求。

6. 结论

6.1 要点总结

SQL Server Always On 可用性组是微软面向关键任务数据库提供的顶级高可用性和灾难恢复解决方案。它们提供数据库级故障转移，无需共享存储；提供可读的辅助副本以卸载工作负载；并具有灵活的地理分布，可实现全面的数据保护。对于仍在运行诸如以下解决方案的组织： 原木运输 or 复制可用性组提供了一种更强大、操作更简单的升级途径。

6.2 何时使用 Always On 可用性组

当需要数据库级高可用性和自动故障转移功能时，请选择可用性组。对于需要为关键数据库提供零数据丢失保护的组织而言，具有自动故障转移功能的同步提交副本将大有裨益。需要读取扩展功能的应用程序可以利用可读辅助副本来分配查询工作负载。

6.3 开始实施

首先评估业务需求，包括恢复时间目标 (RTO)、恢复点目标 (RPO) 和预算限制，以此作为可用性组规划的起点。记录当前数据库基础架构、应用程序依赖关系以及高可用性方面的不足。设计一个既能满足需求又能控制在资源限制范围内的可用性组架构。

案例

• 微软官方文档： 什么是 Always On 可用性组？
• 微软官方文档： Always On 可用性组入门
• 微软官方文档： 分布式可用性组

---

关于作者

袁盛 是一位高级数据库管理员 (DBA)，拥有超过 10 年的 SQL Server 环境和企业数据库管理。他成功解决了金融服务、医疗保健和制造等行业的数百个数据库恢复场景。

袁专长于 SQL Server 数据库恢复、高可用性解决方案和性能优化。他拥有丰富的实践经验，包括管理多TB数据库、实施Always On可用性组以及为关键业务系统开发自动备份和恢复策略。

通过他的技术专长和实践方法，袁致力于创建全面的指南，帮助数据库管理员和 IT 专业人员解决复杂的 SQL Server 高效应对挑战。他始终掌握最新 SQL Server 版本和微软不断发展的数据库技术，定期测试恢复场景以确保他的建议反映现实世界的最佳实践。

有关于的问题 SQL Server 恢复或需要额外的数据库故障排除指导？袁欢迎 反馈和建议 用于改进这些技术资源。