SQL Server AlwaysOn 可用性组搭建要点

dbaai

SQL Server AlwaysOn 可用性组搭建要点

一、具体的问题

很多团队上了 SQL Server 之后，高可用还停留在「一台主库 + 定时备份」的阶段。一旦主库硬件坏了或者做一个大版本升级，业务要停十几分钟甚至更久去恢复，RPO 还可能丢几分钟数据。老板问「能不能做到切换业务无感知」，DBA 才第一次认真看 AlwaysOn。但真正动手时卡在三个具体问题：前置条件到底要准备什么、可用性组（Availability Group，简称 AG）怎么建最稳、出了故障怎么判断该切还是该修。本文把这三点一次说清，让你照着也能把一套两节点 AG 跑起来。

二、核心原理

1. 可用性组解决了什么

它和老的故障转移群集（FCI）不一样：FCI 是「一台实例、共享磁盘」，磁盘才是单点；AG 是「多份独立实例、各自独立数据文件」，把用户数据库在多个副本之间同步，故障切换的是「库」而不是整台实例。读写请求打在主副本（Primary），一个或多个辅助副本（Secondary）持有相同数据的副本，可配置为只读查询或纯粹做备援。等于把单点从磁盘挪到了副本冗余上，主机坏了另一台直接顶上，业务连接串基本不变。

2. 三个绕不开的前置条件

第一，Windows Server 故障转移群集（WSFC）。AG 必须跑在 WSFC 之上，每个 SQL 节点都要加进同一个群集，且群集要用奇数个投票节点或加一个文件共享见证来避免「脑裂」。第二，每个实例都要开启 AlwaysOn 高可用功能——这是在 SQL Server Configuration Manager 里勾选的，光装完实例默认没开。第三，参与同步的库必须处于「完整恢复模式」且至少做过一次完整备份，因为 AG 要靠事务日志把数据连续地送到辅助副本，简单恢复模式的库根本进不了组。

3. 同步提交与异步提交怎么选

同步提交（Synchronous Commit）下，主副本要等辅助副本把日志写盘并返回确认，才向客户端提交成功，所以不会丢数据（RPO=0），代价是有一点写延迟，适合同城双机房。异步提交则不等确认，主库性能不受辅助库影响，但故障切换可能丢最后几秒数据，适合异地灾备。一个常见组合是：同机房第二节点用同步、异地第三节点用异步，既能零丢失又能挡地域级故障。

三、实例参考（动手步骤）

下面以「两台 Windows Server 2019 + SQL Server 2019 标准版」搭一个基础同步 AG 为例，给出可照做的步骤与前后对比。

1) 前置：建群集与开功能（两台都做）
在两台机器都安装故障转移群集角色，其中一台上新建群集（例如集群名 sqlag-clu），并把另一台加入；为节点数为偶数时配置文件共享见证。随后在 SQL Server Configuration Manager 的「SQL Server 服务」属性里，勾选「启用 AlwaysOn 可用性组」，重启服务生效。

2) 准备要进组的数据库（主库执行）

2. -- 确认恢复模式为 FULL，并立即做完整备份 + 日志备份
3. ALTER DATABASE ShopDB SET RECOVERY FULL;
4. BACKUP DATABASE ShopDB TO DISK = 'D:\bak\ShopDB_full.bak';
5. BACKUP LOG ShopDB TO DISK = 'D:\bak\ShopDB_log.trn';

复制代码

把这两个备份文件拷到辅助节点，用 WITH NORECOVERY 还原，让辅助库停在「正在还原」状态等待加入组。

3) 创建可用性组（主库执行）

2. CREATE AVAILABILITY GROUP ag_shop
3.   WITH (AUTOMATED_BACKUP_PREFERENCE = SECONDARY)
4.   FOR DATABASE ShopDB
5.   REPLICA ON
6.     'NODE01' WITH (
7.       ENDPOINT_URL = 'TCP://node01.corp.local:5022',
8.       AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
9.       FAILOVER_MODE = AUTOMATIC),
10.     'NODE02' WITH (
11.       ENDPOINT_URL = 'TCP://node02.corp.local:5022',
12.       AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
13.       FAILOVER_MODE = AUTOMATIC);

复制代码

4) 辅助节点加入组

2. ALTER AVAILABILITY GROUP ag_shop JOIN;
3. ALTER DATABASE ShopDB SET HADR AVAILABILITY GROUP = ag_shop;

复制代码

5) 创建侦听器（供应用连接）
在 SSMS 的 AG 属性里加一个可用性组侦听器，分配固定 IP 与端口（如 1433），应用连接串改用侦听器名而非具体节点名。

6) 验证
在 SSMS 的 AlwaysOn 仪表盘确认主副本、辅助副本都显示「已同步」；用 SSMS 发起一次手动故障转移，观察应用用侦听器名能否无间断重连。

前后对比：搭建前，主库宕机需要人工还原备份，恢复时间约 15 分钟、可能丢数分钟数据；搭建并验证后，自动故障转移在数秒内完成、同步模式下零数据丢失，应用只需重连一次即可继续，RTO 从分钟级降到秒级、RPO 从分钟级降到 0。

四、实操检查清单

• WSFC 是否已建好，节点数为偶数时是否配置了文件共享见证防脑裂？
  
• 每个 SQL 实例的 AlwaysOn 高可用功能是否已在配置管理器勾选并重启生效？
  
• 进组的库是否全部为「完整恢复模式」，且主库已做过至少一次完整备份 + 日志备份？
  
• 辅助节点的库是否用 WITH NORECOVERY 还原、处于「正在还原」状态再 JOIN？
  
• 端点（Endpoint）的端口在两台防火墙是否放行，端点 URL 的域名能否互相解析？
  
• 同步模式是否按距离选择：同城同步、异地异步，避免跨机房同步拖慢主库写入？
  
• 是否创建了可用性组侦听器，应用连接串是否已改为侦听器名而非具体节点？
  
• 是否实际做了一次手动故障转移演练，确认应用能无间断（或仅重连一次）恢复？
  
• 是否配置自动故障转移，并确认两节点服务账户对端点的 CONNECT 权限已授予？
  
• 是否在辅助副本开了只读路由，把报表类只读查询分流过去减轻主库压力？