AzureDeveloper

SQL Server Always On AG（WSFC)配置指南(8) - 创建可用性组

分类: SQL Server ◆ 标签: #SQL Server #SQL Server Always on AG ◆ 发布于: 2026-03-16 18:44:48

我们已经完成了如下工作：

安装了Windows Server
已经配置了网络，禁止了IPV6
创建了域控和DNS
将所有的节点都已经加入了域
安装了SQL Server
安装了故障转移集群
创建和配置了gMSA账户或者专用域账户
为gMSA账户或者专用域账户分配了必要的权限，包括读写SPN以及节点上的文件权限，同时在每个节点上设置了作为服务登录
将已经安装好的SQL Server服务和SQL Agent服务更改成了使用gMSA服务或者专用域账户运行。
配置好了基于SMB共享文件的Witness, 网络路径是:\\hongad\witness
故障转移集群的配置以及共享文件见证的配置
我们在每一台SQL节点上启用了高可用性
我们在每一台SQL节点上为SQL Server服务启用了TCP连接
我们在每一台SQL节点上配置了防火墙，集群内放通了必要的端口。
我们已经确认好了主节点和副本节点，并且已经选择好了需要高可用的数据库，并且在主节点和副本节点上准备好了数据库。

接下来我们创建可用性组。

回到主节点上，使用域管理员账户登录，并打开SSMS工具连接数据库。在左侧的菜单里展开菜单：

在向导对话框里给可用性组取一个名字，另外需要注意如下的几个选项：

群集类型：我们这里只能选择Window Server故障转移群集
数据库级别运行状况检测(H):
- 作用：
  此选项启用后，WSFC 不仅监控 SQL Server 服务实例的整体状态，还会单独监控可用性组中每个数据库的健康状况。
- 工作原理：
  未启用时：如果 SQL Server 实例正在运行，WSFC 就认为该节点是健康的，即使某个特定的数据库处于“可疑（Suspect）”、“恢复中（Restoring）”或“离线”状态。这可能导致故障转移到一个数据库本身有问题的节点上。
  启用后：WSFC 会查询 sys.dm_hadr_database_replica_states。如果主副本上的某个数据库状态不健康（例如损坏或无法访问），WSFC 可以将该资源标记为失败，从而触发故障转移，尝试将角色切换到另一个拥有健康数据库副本的节点。
- 适用场景：
  强烈建议在大多数生产环境中启用此选项。它能提供细粒度的保护，防止因为单个数据库损坏而导致整个应用程序不可用，确保持续可用性。
每数据库DTC支持:
- 作用：
  此选项控制是否允许可用性组中的特定数据库参与分布式事务（由 Microsoft 分布式事务协调器 MSDTC 管理）。
- 背景与选项含义：
  在旧版本或默认配置中，DTC 支持通常是针对整个 SQL Server 实例启用的。但在 Always On AG 中，为了更灵活地管理涉及跨节点或跨服务器的分布式事务，引入了更细粒度的控制。
  启用（每数据库）：允许你为可用性组内的每个数据库单独配置是否支持 DTC。这对于混合环境非常重要，即某些数据库需要参与分布式事务，而其他数据库不需要。
- 技术细节：
  当启用此选项时，SQL Server 会在 WSFC 中为每个支持 DTC 的数据库创建独立的 DTC 资源依赖关系。这意味着如果发生故障转移，DTC 上下文可以随特定的数据库一起移动，确保事务的一致性。
- 适用场景：
  如果你的应用程序使用分布式事务（例如使用 BEGIN DISTRIBUTED TRANSACTION 或链接服务器进行跨库更新），并且这些事务涉及 Always On 可用性组中的数据库，则必须正确配置此项。通常建议选择“每数据库”以获得最大的灵活性，或者根据具体的架构需求选择“无”或“实例级”。
重用系统数据库:
生产环境绝对不要勾选！它允许你将 master、msdb、model 等系统数据库加入到可用性组中，使它们在辅助副本上也可读（或同步）。99.9% 的生产场景中，这是一个错误的配置。
- 适用场景：
  仅限于极其特殊的开发/测试环境，或者你需要将登录名（Logins）、作业（Jobs）完全同步到备库的特定架构，但即使如此，也有更好的替代方案。

继续下一步选择符合条件的数据库，因为我们之前已经准备好了数据库，因此这里可以直接选择：

继续下一步之后，添加必要的副本节点：

注意这里的选项：

自动转移故障：当主副本所在的节点发生故障（如服务器宕机、SQL服务停止、网络断开）时，WSFC 会自动检测到并将可用性组角色切换到另一个健康的同步副本上，无需人工干预。
- 是否要选择？
  - 选“是”的情况：
    - 你需要极高的可用性（HA），要求业务中断时间最短（通常几秒到几十秒）。
    - 你的主备节点在同一个局域网内（满足同步提交的延迟要求）。
    - 你有运维团队监控，但希望系统能自我修复常见硬件/软件故障。
  - 选“否”（手动故障转移）的情况：
    - 你使用的是“异步提交”模式（此时该选项通常是灰色的，不可选）。
    - 虽然是同步模式，但你担心“脑裂”或网络波动导致不必要的频繁切换，希望由 DBA 确认后再切换（较少见，通常 HA 都追求自动）。
    - 跨机房部署，虽然强行配了同步，但为了安全起见只打算手动切换（不推荐这种架构，跨机房通常直接用异步）。
可用性模式：同步提交 (Synchronous) vs 异步提交 (Asynchronous)这个选择的核心权衡是：数据零丢失 vs 主库性能/延迟。
- 同步提交 (Synchronous Commit)
  - 工作原理：
    事务在主副本（Primary）提交之前，必须等待至少一个辅助副本（Secondary）确认已将日志写入磁盘。
  - 优点：
    - 理论上不会丢失任何已提交的数据。如果主节点宕机，辅助节点拥有完全一致的数据。
    - 自动故障转移的基础：只有同步提交的副本才能参与自动故障转移。
  - 缺点：
    - 增加延迟：事务的响应时间取决于网络延迟和辅助节点的磁盘写入速度。如果辅助节点慢或网络抖动，主库的写入性能会直接下降。
    - 距离限制：通常要求主备节点在同一个数据中心或极低延迟的网络环境（通常建议延迟 < 5-10ms）。
  - 适用场景：
    - 金融、医疗等对数据一致性要求极高，不能容忍任何数据丢失的系统。
    - 主备节点位于同一城市/同一局域网内（低延迟）。
    - 需要配置“自动故障转移”。
- 异步提交 (Asynchronous Commit)
  - 工作原理：主副本提交事务后，立即向客户端返回成功，不需要等待辅助副本确认。日志随后会被发送到辅助节点。
  - 优点：
    - 高性能：主库的写入性能几乎不受辅助节点影响。
    - 长距离支持：适用于跨城市、跨地域的灾难恢复（DR），即使网络延迟较高（几十毫秒甚至几百毫秒）也不会拖慢主库。
  - 缺点：
  - 如果主节点发生灾难性故障（如断电且存储损坏），在故障发生瞬间尚未发送到辅助节点的日志会丢失，导致少量数据丢失。
  - 只能手动故障转移：不支持自动故障转移（因为无法保证数据完全一致，自动切换可能导致数据丢失风险，SQL Server 强制要求手动确认）
  - 适用场景：
    - 跨数据中心、跨城市的灾备场景。
    - 对写入吞吐量要求极高，且能容忍极少量数据丢失（秒级）的非核心业务。
    - 辅助节点主要用于报表查询（Readable Secondary），不希望影响主库性能。
可读辅助副本:
是 SQL Server Always On 可用性组的一个核心高级功能。是否勾选取决于你的业务需求，特别是你是否需要利用备用节点来分担主库的压力。在传统的数据库镜像（Database Mirroring）或旧版日志传送中，备用数据库通常处于“还原中”状态，无法被访问。而可读辅助副本允许你在辅助节点上以只读方式打开数据库。仅在向导中勾选“可读辅助副本”是不够的，要让这个功能真正生效并发挥作用，你通常还需要配置以下两点：
- 配置“只读路由” (Read-only Routing URL)
  在创建 AG 后，你需要为每个副本配置一个 URL(通常是 TCP://服务器名:端口), 这告诉集群：“如果有只读请求进来，请把它转发到这个地址”。
- 配置“只读路由列表” (Read-only Routing List): 定义当主库故障转移后，读请求应该按什么顺序尝试连接哪些辅助副本。
- 应用程序连接字符串修改: 应用程序的连接字符串必须包含 Application Intent=ReadOnly 参数。

继续下一步，因为我们之前已经准备好了数据库，因此这里选择”仅连接“

完整可用性组创建：