SQL Server 故障转移集群（Failover Cluster Instance，简称 FCI）和 Always On 可用性组（Availability Group，简称 AG）经常被放在一起比较，但两者的保护粒度完全不同。FCI 是在 Windows Server 故障转移群集（WSFC）之上构建的实例级高可用方案，所有集群节点共享同一份存储，对外只暴露一个虚拟服务器名称和虚拟 IP。而 AG 则是数据库级的高可用方案，每个副本拥有独立的 SQL Server 实例和独立存储，通过专用的日志传输机制保持数据同步。理清这两者的架构差异，是设计 SQL Server 高可用策略的前提。
一、架构层次：实例级冗余与数据库级冗余
SQL Server 故障转移集群的核心思想是让多个物理节点共享同一个 SQL Server 实例。在 FCI 架构中，群集中的每个节点都安装了相同版本的 SQL Server，但同一时间只有一个节点能对外提供服务，这个节点称为活动节点。其他节点处于待命状态，不处理客户端请求。所有节点的 SQL Server 服务使用同一个数据库文件，这些文件存放在共享存储上，例如 SAN 或 iSCSI 磁盘。当活动节点出现故障时，WSFC 会把 SQL Server 服务、虚拟网络名称、虚拟 IP 以及共享磁盘等资源整体切换到另一个节点，整个过程对客户端来说只是连接中断后重新连接，无需修改连接字符串。
相比之下，Always On 可用性组的工作方式更像数据库镜像的升级版。AG 不是一个实例级的集群技术，而是把一组用户数据库作为一个逻辑单元进行复制。每个副本都位于不同的 SQL Server 实例上，这些实例可以部署在不同的物理服务器或虚拟机上，每个实例都有自己的本地存储，不需要共享磁盘。AG 通过一个侦听器（Listener）对外提供统一的连接入口，客户端连接到侦听器后，会自动路由到当前主副本或配置为可读的辅助副本。这种设计让 AG 既能实现高可用，也能支持只读负载分担。
从资源依赖角度看，FCI 强依赖共享存储，这意味着共享存储本身必须是高可用的，否则会形成新的单点故障。AG 则完全不依赖共享存储，每个副本的数据文件独立存放，更适合云环境或跨机房部署。不过 AG 仍然需要 WSFC 提供底层的群集仲裁和健康检测，如果 WSFC 本身不可用，AG 的自动故障转移也会受到影响。
二、数据同步与故障转移机制对比
数据同步是 FCI 和 AG 最大的差异之一。FCI 因为共享存储，所有节点读取的是同一份数据，所以不存在数据同步问题，也谈不上数据延迟。故障转移时，新的活动节点直接接管同一份数据库文件，恢复时间主要取决于 SQL Server 服务的启动和数据库恢复过程，通常是秒级或分钟级。这种模式下，RPO（恢复点目标）为零，因为任何已提交的事务都写入共享磁盘，不会丢失。但共享存储的 I/O 性能会成为整个集群的瓶颈，而且存储故障会直接导致整个实例不可用。
AG 的数据同步基于事务日志流。主副本上的事务提交后，日志记录会发送到所有辅助副本，辅助副本将日志固化到本地磁盘并重做（redo）以保持数据一致。AG 支持两种提交模式：同步提交和异步提交。同步提交模式下，主副本必须等待至少一个辅助副本确认日志已固化，事务才能提交成功，这样可以保证零数据丢失，但会增加事务延迟。异步提交模式下，主副本不等待辅助副本确认，事务延迟低，但故障转移时可能丢失部分已提交的事务。管理员可以根据副本的分布和网络质量灵活选择。
故障转移机制方面，FCI 的故障转移由 WSFC 协调，可以设置为自动或手动。自动故障转移通常由心跳检测触发，检测到活动节点无响应后，WSFC 会在几秒到几十秒内将资源组切换到其他节点。AG 的自动故障转移仅适用于同步提交模式下的副本，并且需要副本配置为自动故障转移。主副本故障时，WSFC 和 AG 的仲裁机制会共同决定哪个辅助副本提升为主副本。异步副本通常只支持手动强制故障转移，可能伴随数据丢失，所以一般用于灾难恢复。
下面的查询可以查看当前可用性组各副本的同步状态，帮助运维判断故障转移的可靠性：
-- 查询可用性组的同步状态
SELECT
ag.name AS availability_group_name,
ar.replica_server_name,
ars.synchronization_health_desc,
ars.synchronization_state_desc,
ars.role_desc
FROM sys.availability_groups ag
JOIN sys.availability_replicas ar ON ag.group_id = ar.group_id
JOIN sys.dm_hadr_availability_replica_states ars ON ar.replica_id = ars.replica_id;
这段查询结果中，synchronization_health_desc 显示 HEALTHY 表示副本同步正常，synchronization_state_desc 显示 SYNCHRONIZED 或 SYNCHRONIZING 可以反映实时状态。如果主副本和辅助副本都处于同步提交且状态健康，自动故障转移就不会丢失数据。
三、如何选择：部署场景与组合方案
选择 FCI 还是 AG，首先要明确业务对可用性的要求以及现有的基础设施。如果应用无法接受修改连接字符串，或者需要保护的是整个 SQL Server 实例，包括系统数据库（master、model、msdb）和作业、登录等实例级对象，那么 FCI 是更合适的选择。FCI 对应用透明，连接字符串中的服务器名称是虚拟网络名称，故障转移后名称不变。但 FCI 需要共享存储，硬件采购和运维成本较高，而且通常只能在一个数据中心内部署，跨机房的存储复制方案复杂且昂贵。
如果业务的核心诉求是数据库级高可用，同时希望利用辅助副本分担只读查询或备份压力，AG 的优势就非常明显。AG 不要求共享存储，可以将副本分布在不同机架、不同机房甚至不同地域，实现真正的异地容灾。AG 还支持最多 8 个辅助副本，这些副本可以配置为可读，客户端通过只读路由自动分发到辅助副本，有效降低主副本压力。不过 AG 不保护实例级对象，登录、作业、链接服务器等需要额外同步，而且每个副本都必须安装相同版本的 SQL Server，维护多个独立实例也增加了管理复杂度。
在实际生产环境中，很多高可用架构会同时使用 FCI 和 AG。例如，在同一数据中心内使用 FCI 保护实例级故障，避免单台服务器硬件故障导致停机；同时在两个数据中心之间使用 AG 实现数据库级异步复制，防止整个站点故障。这种组合能兼顾本地高可用和异地容灾，但部署和运维难度也最高，需要对 WSFC、仲裁配置、网络延迟和存储性能有深入理解。
最后需要提醒的是，无论选择哪种方案，都不能忽视基础备份和恢复策略。高可用解决的是服务连续性，备份解决的是数据逻辑错误或人为误操作。只有把 FCI 或 AG 与完善的备份、监控、演练体系结合起来，才能构建真正可靠的 SQL Server 运行环境。
Always On可用性组SQL Server故障转移集群高可用性修改时间：2026-10-05 10:27:47