故障转移群集（Failover Cluster Instances）和AlwaysOn是SQL Server中两种不同的高可用性解决方案

 

一、完整英文全称

SQL Server Always On Failover Cluster Instances
 
直译：SQL Server 始终在线故障转移群集实例

分段拆解

  1. Failover：故障转移
  2. Cluster：群集
  3. Instances：实例（复数）

二、标准缩写

FCI
 
完整对应：Failover Cluster Instances

三、补充区分配套概念

  1. Always On Availability Groups
     
    全称：始终在线可用性组
     
    缩写：AG
  2. 整体技术栈统称：SQL Server Always On（无缩写）

四、标准书写规范

  • 全称：Failover Cluster Instance（单数，单实例）
  • 复数：Failover Cluster Instances
  • 通用简写：FCI（行业通用、微软文档统一标识）

AlwaysOn 完整官方英文全称与释义

1. 标准全称

SQL Server Always On Availability Groups
 
日常简称：Always On AG（可用性组）

2. 名词拆分说明

  • Always On：持续在线、永久可用
  • Availability Groups：可用性组

3. 细分组件完整命名

  1. Always On Availability Groups（核心主功能，高可用读写集群）
  2. Always On Failover Cluster Instances (FCI)（故障转移集群实例）
     
    统一对外统称「SQL Server Always On」技术栈。

4. Microsoft 官方定义

SQL Server Always On 是一套企业级高可用与灾难恢复解决方案，包含可用性组与故障转移集群实例两大技术，实现数据库自动故障转移、读写分离、异地容灾，保障业务数据库持续在线。

补充说明

  1. Always On 不是缩写词，是微软组合专有名词，无字母缩写展开；
  2. 行业书写规范：技术名称标准写法 Always On（分开），口语常连写 AlwaysOn；
  3. 核心作用：替代传统数据库镜像，支持多副本、自动故障切换、只读副本分流业务查询。

SQL Server FCI 与 AG：新认知 + 元认知分层解读

一、旧认知（传统浅层认知，运维初学者普遍误区）

1. 对 FCI 的老旧认知

  1. FCI 就是 “双机热备”，和 AG 一样都是数据库高可用；
  2. FCI 可以做异地容灾、读写分离；
  3. FCI 数据更安全，AG 会丢数据；
  4. FCI 和 AG 二选一，不能组合使用；
  5. FCI 切换快、零延迟，适合所有业务。

2. 对 AG 的老旧认知

  1. AG 只是多副本同步备份，不能做核心交易高可用；
  2. AG 必须企业版，标准版完全没用；
  3. AG 同步一定丢数据，异步才是主流；
  4. AG 能替代 FCI，不需要共享存储就全面优于 FCI；
  5. AG 自动同步登录、作业、系统配置，部署完直接可用。

3. 二者统一浅层误区

  1. 二者是同级替代关系，只能选一种；
  2. Always On 是单一技术，FCI、AG 只是名字不同；
  3. 故障转移速度越快架构越好；
  4. 只看 RPO，忽略存储单点、资源利用率、运维成本等综合指标。

二、全新专业认知（底层架构 + 生产落地视角，打破误区）

（一）FCI（Failover Cluster Instance）全新认知

  1. 本质是「实例级共享存储集群」，不是数据复制架构
     
    FCI 无日志同步、无数据副本，所有节点共用一份存储；高可用只解决服务器硬件 / OS/SQL 服务故障，无法规避存储损毁风险，共享磁盘是天然单点故障。
  2. 性能优势仅局限高写入场景，存在硬性资源浪费
     
    主节点承载全部读写，备节点全程闲置，硬件利用率极低；同步无延迟仅适用于本地机房，跨机房共享存储成本极高，几乎不用于异地灾备。
  3. 保护范围全覆盖，但切换代价大
     
    切换时整实例重启、所有数据库同时下线，恢复时间受数据库大小影响，大库 RTO 可达数十分钟；系统库、登录、代理、存储过程自动跟随，不用人工同步是唯一独有优势。
  4. 适用边界清晰：仅本地核心高频写、无异地需求场景
     
    一旦有异地容灾、读写分离、多库故障隔离需求，单一 FCI 架构存在天然短板。

（二）AG（Availability Groups）全新认知

  1. 本质是「数据库级日志复制架构」，副本独立存储，无存储单点
     
    各副本本地独立磁盘，依靠事务日志持续同步，从根源规避共享存储损坏全盘丢失风险；支持同步 / 异步双模式，同步副本可实现 RPO=0，异步适配异地灾备。
  2. 读写分离是 AG 独有核心价值，硬件资源充分复用
     
    次要副本可承载报表、统计、全量备份、只读查询，大幅分流主库压力，解决 FCI 备机闲置浪费问题。
  3. 粒度更精细，故障隔离能力更强
     
    按可用性组分组切换，单一组故障不影响其他业务库；但仅复制用户库，master、msdb、登录、作业、权限均需配套同步脚本维护，运维复杂度上升。
  4. 版本分层能力：标准版可用作轻量双副本，企业版支持 9 副本复杂架构
     
    标准版 2 副本同步 AG 可满足中小企业本地高可用，并非只有大企业才能使用；多副本架构可实现本地同步 + 异地异步两地三中心标准灾备。
  5. 同步模式存在写入延迟损耗，是不可规避的性能代价
     
    同步提交事务需等待副本落盘才返回应用，高并发写入场景会产生等待，不适合极致低延迟核心交易。

（三）二者关系全新认知：非替代，可叠加互补（FCI+AG 混合架构）

  1. FCI 解决单机房服务器硬件故障，AG 解决机房级灾难、异地容灾、读写分离；
  2. 标准金融核心架构：本地双节点 FCI 保证本地零丢失高可用，异地独立实例作为 AG 异步副本抵御机房整体损毁；
  3. 二者同属 Always On 技术栈，但底层实现、存储模型、故障粒度、容灾能力完全独立，互补而非竞争。

（四）选型标准全新认知：不存在绝对优劣，以业务约束为判定依据

  1. 追求极致写入低延迟、实例统一管控、无异地需求 → FCI；
  2. 需要读写分离、异地灾备、规避存储单点、多库故障隔离 → AG；
  3. 本地高可用 + 异地灾备双重诉求 → FCI 嵌套 AG 混合架构。

（五）风险全新认知

  1. FCI 最大风险：存储单点故障，SAN/CSV 损坏会全盘数据丢失；
  2. AG 最大风险：同步模式写入性能损耗、配置项不同步带来运维一致性故障、异步副本存在秒级数据丢失可能。

三、元认知（对两种架构的思维、边界、选型逻辑的顶层反思）

元认知核心：跳出功能对比，思考我们如何定义高可用、如何权衡技术取舍、如何看清两种方案的能力边界与设计初衷。

1. 架构设计初衷元认知

  1. FCI 诞生背景：早年存储昂贵、无日志复制技术，依靠共享磁盘实现实例级热备，核心目标是服务器故障快速接管，设计时未考虑异地、读写分流；
  2. AG 诞生背景：解决 FCI 共享存储单点、资源浪费、无法跨机房三大痛点，基于事务日志复制重构高可用体系，核心目标是分布式多副本容灾与负载分流。
     
    二者是不同时代、不同业务诉求下的两套解决方案，设计目标本身就存在差异，不能单一评判好坏。

2. 高可用评判标准元认知

初学者仅以「是否零数据丢失」作为唯一标准；
 
成熟运维的多维评判体系：
  • RPO（数据丢失量）
  • RTO（故障恢复时长）
  • 单点故障面（存储 / 服务器 / 机房）
  • 硬件资源利用率
  • 写入性能损耗
  • 运维复杂度与人力成本
  • 异地灾备扩展能力
     
    单一指标无法判定架构优劣，必须结合业务 SLA 综合权衡。

3. 边界认知元认知（清晰区分二者 “能做、做不到”）

FCI 能力边界

✅ 能：实例全量保护、系统对象自动同步、写入无延迟、本地零丢失
 
❌ 做不到：异地低成本容灾、读写分离、多库独立故障隔离、规避存储单点

AG 能力边界

✅ 能：多副本冗余、异地灾备、读写分流、无存储单点、数据库粒度切换
 
❌ 做不到：实例配置自动同步、极致低延迟高并发写入、全局统一实例切换
元认知关键：任何架构都存在固有的能力短板，不存在万能高可用方案，选型本质是接受短板换取对应优势。

4. 选型思维元认知（破除非黑即白的二元思维）

  1. 摒弃 “FCI 过时 / AG 全面领先” 的极端思维，业务场景决定架构；
  2. 简单场景（小型本地单实例、无报表查询）FCI 运维成本更低，是更优解；
  3. 复杂分布式、多业务、异地多活场景，AG 是刚需；
  4. 复杂核心交易场景可融合两套架构，取长补短，打破 “二选一” 固化思维。

5. 运维风险管控元认知

  1. FCI 运维重心：存储冗余、SAN/CSV 巡检、存储链路高可用，防范存储单点崩溃；
  2. AG 运维重心：日志同步链路监控、账号 / 作业同步、副本延迟告警、区分同步 / 异步丢失风险；
  3. 元认知结论：架构不同，运维风险面完全不同，监控、巡检、应急预案需要针对性设计，不能一套脚本通用两套架构。

6. 成本收益元认知

  1. FCI 短期硬件成本高（共享存储），长期运维人力成本低；
  2. AG 无需共享存储，硬件初始投入更低，但长期运维、监控、配置同步带来持续人力成本；
     
    选型不能只看一次性采购成本，需要测算全生命周期综合成本。

7. 技术迭代元认知

随着 SQL Server 版本迭代，AG 能力持续增强（多副本、分布式 AG、自动种子填充），逐步覆盖大量 FCI 使用场景；但 FCI 依靠无写入延迟、实例全同步的独有特性，在金融核心交易场景仍不可替代，二者会长期共存，不存在单方面淘汰另一方。

四、三层认知总结对照表

认知层级 思考视角 核心观点
浅层旧认知 功能表层使用 FCI 和 AG 都是双机热备，二选一，AG 更强 / FCI 更安全
全新专业认知 底层架构、生产落地 FCI = 共享存储实例级集群；AG = 日志复制数据库副本；二者可混合部署，各有明确适用边界
元认知 顶层选型、架构取舍、风险思维 两种架构设计目标不同，各有固有短板；高可用需要多维度 SLA 综合评判，结合业务取舍，不存在万能方案

SQL Server FCI（Failover Cluster Instances）与 AG（Availability Groups）完整对比

一、基础全称与缩写

  1. FCI
     
    全称：SQL Server Always On Failover Cluster Instances
     
    中文：Always On 故障转移群集实例
     
    定位：实例级本地高可用方案，依赖 WSFC 共享存储集群Microsoft Learn
  2. AG
     
    全称：SQL Server Always On Availability Groups
     
    中文：Always On 可用性组
     
    定位：数据库级高可用 + 异地容灾方案，各副本独立本地存储Microsoft Learn

二、核心底层原理差异

1. FCI 故障转移群集实例

  1. 一套 SQL 实例跨多台 WSFC 节点安装，全局共用一套共享存储（SAN/S2D/CSV），同一时间仅 1 个节点挂载磁盘、运行 SQL 服务。
  2. 故障逻辑：节点宕机 → WSFC 切换存储磁盘所有权、虚拟 IP / 虚拟名转移至备节点 → 备节点启动 SQL 实例、执行实例级 crash recovery。
  3. 数据机制：无日志复制，所有节点读写同一份物理数据库文件，天然零数据丢失（RPO=0）。
  4. 读写限制：备用节点无数据库副本，切换前完全不可访问。

2. AG 可用性组

  1. 多套独立 SQL 实例（副本），每台服务器使用本地独立磁盘，无共享存储；主库通过事务日志流复制同步至所有副本数据库Microsoft Learn。
  2. 两种同步模式：
    • 同步提交：主事务等待副本落盘再返回应用，RPO=0；
    • 异步提交：主库先提交、后台异步推送日志，存在少量数据丢失风险，适合异地容灾。
  3. 故障逻辑：单库 / 实例故障仅切换对应数据库组，其他数据库不受影响；次要副本常态支持只读访问。

三、全维度详细对比表

对比维度 FCI（Failover Cluster Instances） AG（Availability Groups）
保护粒度 实例级别：覆盖全实例所有库、系统库、登录、代理作业、服务器配置 数据库级别：仅保护加入可用性组的用户库，系统库不复制
存储架构 必须共享存储（SAN、S2D、CSV），所有节点共用一份数据文件 各副本独立本地存储，无共享存储，无存储单点故障
数据同步方式 无复制，共享磁盘；切换仅移动存储所有权 事务日志流复制，主库实时推送日志至次要副本
次要节点访问 切换前完全不可读写，仅待机 次要副本常态支持只读（报表、备份分流）
故障转移范围 实例整体切换，所有数据库同时离线切换 支持单 AG 独立切换，多 AG 互不干扰，粒度更细
跨机房 / 异地容灾 极难，依赖跨机房共享存储，成本极高 原生支持异地异步副本，主流两地三中心容灾架构
数据库恢复模式 无强制要求，Simple / 完整 / 大容量日志均可 所有库必须为完整恢复模式，否则无法加入 AG
许可版本限制 标准版、企业版均支持 标准版最多 2 副本；企业版支持最多 9 副本、多同步副本
RPO 数据丢失 0 丢失（共享存储天然一致） 同步提交 RPO=0；异步提交存在秒级丢失风险
RTO 恢复时长 较长（30 秒～20 分钟）：挂载磁盘 + 完整实例恢复 较短（<30 秒）：数据库快速重做日志
性能开销 几乎无写入延迟，不阻塞业务事务 同步副本会增加主库写入等待延迟
单点故障风险 共享存储为核心单点，存储损坏数据全部丢失 无存储单点，单副本故障不影响其他副本
负载分流能力 无，仅单一活动节点承载全部读写 读写分离，报表、备份卸载至只读副本
部署复杂度 本地机房部署简单；跨机房成本极高 本地、异地部署灵活，架构更复杂，运维成本更高
典型故障场景适配 服务器 OS、硬件、SQL 实例服务崩溃 单库损坏、实例宕机、机房整体灾难、读写分离业务

四、优缺点总结

FCI 故障转移群集实例

✅ 优势
  1. 实例级完整保护，登录、存储过程、代理任务、系统库全部同步；
  2. 写入无同步延迟，高并发写业务性能无损；
  3. 架构简单，日常运维工作量小；
  4. 零数据丢失，金融核心写业务首选本地高可用。
❌ 劣势
  1. 共享存储存在单点故障；
  2. 备节点无法利用，硬件资源浪费；
  3. 不支持读写分离，所有压力集中在主节点；
  4. 异地容灾部署成本极高、扩展性差。

AG 可用性组

✅ 优势
  1. 无共享存储，规避存储单点故障；
  2. 支持只读副本分流查询、备份，提升硬件利用率；
  3. 原生支持异地异步副本，完美满足两地三中心灾备；
  4. 数据库粒度故障切换，故障影响范围更小；
  5. 多副本架构，可做多级数据冗余。
❌ 劣势
  1. 同步模式会带来业务写入延迟；
  2. 仅复制用户数据库，登录、作业、配置需手动同步；
  3. 所有业务库强制完整恢复模式，日志量大幅增加；
  4. 架构复杂，监控、故障排查难度高于 FCI。

五、适用业务场景

选择 FCI 的场景

  1. 本地机房核心高写入数据库，无法容忍同步延迟；
  2. 实例内几十上百个数据库，希望统一实例级故障切换；
  3. 不需要读写分离、无异地灾备需求；
  4. 追求极简运维、预算有限、仅本地双机热备。

选择 AG 的场景

  1. 需要异地机房容灾、两地三中心架构；
  2. 读多写少业务，需要把报表、统计查询卸载到备机；
  3. 规避共享存储单点风险；
  4. 数据库数量少、需要独立分组故障隔离；
  5. 需在线迁移、分库分库扩容场景。

六、混合架构（生产最高可用方案：FCI + AG）

本地机房部署一套 FCI 做本地实例高可用（解决服务器硬件故障），再新增一套独立实例作为 AG 异步副本放置异地机房：
  1. FCI 保证本地服务器宕机零丢失快速切换；
  2. AG 日志复制同步至异地机房，抵御机房整体断电、火灾等灾难性故障；
  3. 同时兼顾本地高可用与异地容灾，是金融、政企核心数据库标准架构。

七、核心一句话区分

  • FCI = 共享磁盘、实例整体切换、本地高可用、无读写分离
  • AG = 独立磁盘、日志复制、数据库粒度切换、支持异地容灾与读写分离

SQL Server Always On Failover Cluster Instances（FCI）底层完整原理

一、前置基础：依赖 Windows Server Failover Cluster（WSFC）

FCI 并非 SQL Server 独立组件，完全依托 Windows 故障转移群集 WSFC实现，整套底层分为三层：
  1. 底层：Windows 群集服务 ClusSvc、群集磁盘资源、群集网络（虚拟 IP、客户端访问点 CAP）
  2. 中间层：共享存储层（SAN/CSV/S2D），所有群集节点共享同一套数据库物理文件
  3. 上层：SQL Server 群集实例，绑定群集资源，受 WSFC 统一管控
核心本质：多节点共用一份磁盘数据，同一时刻仅一台节点持有磁盘所有权并运行 SQL 服务，故障时 WSFC 自动移交资源至备用节点。

二、三大核心底层组件工作原理

1. WSFC 群集仲裁机制（节点健康判定核心）

  1. 所有节点通过心跳网络互相发送心跳包（默认 1 秒一次）；
  2. 仲裁见证（磁盘见证 / 文件共享见证 / 云见证）用于解决脑裂：
     
    若节点间网络中断，持有仲裁投票的一方获得资源接管权限，避免双节点同时挂载共享磁盘造成文件损坏；
  3. 群集持续监控三类资源健康状态：
    • 共享磁盘资源（数据库存储）
    • 客户端访问点 CAP（虚拟计算机名 + 虚拟 IP）
    • SQL Server 服务资源（sqlservr.exe）
       
      任意资源故障触发故障转移流程。

2. 共享存储底层机制（FCI 与 AG 最本质区分点）

  1. 存储架构：SAN 光纤存储、iSCSI、Storage Spaces Direct（S2D）、集群共享卷 CSV；
  2. 磁盘独占锁机制：
     
    共享磁盘同一时间仅允许一个节点挂载读写，Windows 群集通过 SCSI 预留锁（Persistent Reservation）锁定磁盘；
     
    备用节点仅能识别磁盘、无法读写，无任何独立数据副本；
  3. 数据一致性保障：
     
    不存在日志复制、无数据同步过程，所有节点访问完全同一组 MDF/LDF 文件，天然 RPO=0，不会出现主备数据不一致；
  4. 读写流程：
     
    业务请求 → 虚拟 IP → 当前活动节点 → 共享磁盘读写，备节点无 IO 通道。

3. 客户端访问点 CAP（虚拟名 / 虚拟 IP）

  1. FCI 对外不使用物理节点 IP / 主机名，统一使用群集虚拟网络名称；
  2. 虚拟 IP 资源随故障转移同步漂移：
     
    主节点故障后，虚拟 IP 解绑主网卡，在备节点网卡启用，DNS 自动刷新；
  3. 应用连接字符串无需修改，全程无感切换节点。

三、完整正常运行底层流程

  1. WSFC 仲裁投票完成，选举活动节点；
  2. 活动节点获取共享磁盘持久预留锁，挂载磁盘盘符；
  3. 群集启动 CAP 虚拟 IP、虚拟计算机名资源；
  4. 群集启动 SQL Server 群集实例服务，加载 master、model 等系统库与业务库；
  5. 应用通过虚拟 IP 接入 SQL，所有读写落地共享存储；
  6. 备用节点持续发送心跳监控主节点状态，磁盘保持只读锁定待机。

四、故障转移完整底层执行链路（节点宕机 / 服务崩溃）

阶段 1：故障检测

  1. 主节点心跳超时、sqlservr 服务意外终止、存储链路中断；
  2. WSFC 判定节点资源失效，标记故障节点为离线。

阶段 2：资源隔离（防脑裂）

  1. 对故障节点发送 SCSI 解除预留指令，强制剥夺磁盘读写权限；
  2. 故障节点失联后磁盘锁失效，防止双节点同时写入撕裂数据库文件。

阶段 3：资源迁移至备用节点

  1. 备用节点争夺仲裁投票，获取共享磁盘持久预留锁，挂载磁盘；
  2. 在备节点网卡激活虚拟 IP、注册虚拟计算机名；
  3. 群集按依赖顺序启动 SQL Server 服务。

阶段 4：SQL Crash Recovery 崩溃恢复

  1. SQL 启动后读取事务日志 LDF，执行崩溃恢复：
    • 已提交事务写入数据文件；
    • 未提交事务回滚撤销；
  2. 所有数据库恢复在线，业务通过原虚拟 IP 重连，故障转移完成。
关键特征：整个切换过程无日志同步、无数据拷贝，仅迁移磁盘所有权与网络资源；数据库恢复耗时取决于日志大小、库文件总量。

五、SQL Server 群集实例专属底层特性

  1. 实例全域统一
     
    登录名、代理作业、DTS 包、系统库 master/msdb/tempdb 全部存放在共享磁盘，切换后完整保留，无需人工同步配置（AG 不具备该特性）。
  2. Tempdb 存放于共享磁盘
     
    临时数据随实例一同漂移，多节点不会产生独立临时文件。
  3. SQL 资源依赖关系
     
    WSFC 强制依赖顺序：磁盘资源 → 虚拟 IP → 虚拟名称 → SQL 服务；
     
    磁盘未挂载完成，不会启动数据库引擎。
  4. 无副本数据、无同步开销
     
    不存在日志捕获、传输、重做流程，高并发写入无同步等待延迟，这是 FCI 核心性能优势。

六、底层固有短板（架构天生限制）

  1. 共享存储单点故障
     
    整套数据仅一份，SAN / 磁盘阵列损坏、RAID 失效将直接全部丢失数据；无副本冗余机制。
  2. 备用节点资源完全闲置
     
    磁盘被独占锁定，备节点无法读取数据库，不能承担报表、备份等只读业务，硬件利用率低。
  3. 跨机房部署底层约束极强
     
    异地机房共享存储需要长距离光纤、延伸集群，硬件成本极高；远距离链路波动极易触发故障转移，不适合异地灾备。
  4. 故障转移 RTO 偏长
     
    大数据库崩溃恢复需要遍历完整事务日志，数十 GB 日志会拉长业务中断时间。

七、FCI 底层与 AG 可用性组核心底层差异总结

  1. 存储底层：FCI = 单份共享磁盘；AG = 多副本独立本地磁盘
  2. 数据同步底层：FCI = 无复制，磁盘锁独占；AG = 事务日志流式复制
  3. 故障转移对象：FCI = 整实例、全库一起切换；AG = 单可用性组、数据库粒度切换
  4. 备节点底层 IO：FCI 备机无读写权限；AG 副本支持持续只读 IO
  5. 数据丢失风险：FCI 仅存储硬件损坏丢数据；AG 异步模式存在秒级数据丢失

SQL Server Always On Availability Groups（AG）完整底层原理

一、核心基础架构总览

AG 不依赖共享存储，底层两大支撑：
  1. Windows Server Failover Cluster（WSFC）：负责健康心跳、仲裁、故障转移、侦听器虚拟 IP；
  2. SQL Server 事务日志流复制引擎：主副本向所有次要副本同步数据，是 AG 核心数据同步机制。
核心本质：多套独立 SQL 实例、本地独立磁盘，依靠事务日志持续同步多份完整数据库副本；支持数据库粒度故障切换、只读分流、异地容灾。
整体分层：
  • 集群层：WSFC 心跳、仲裁、AG 侦听器（Listener）
  • SQL 同步引擎层：日志捕获、日志传输、日志重做、同步提交控制
  • 存储层：各副本独立本地 MDF/LDF，无共享磁盘、无 SCSI 磁盘锁

二、前置硬性底层约束（由同步机制决定）

  1. 加入 AG 的数据库必须设置为完整恢复模式；
  2. 必须先做完整备份 + 日志备份初始化副本；
  3. 系统库 master、msdb、tempdb 不参与日志同步，登录、作业、权限需外部脚本同步；
  4. 每个副本持有一份完整数据库物理文件，数据天然多副本冗余。

三、四大核心底层模块详解

模块 1：WSFC 集群支撑（集群协调底座）

  1. 节点心跳检测
     
    所有参与 AG 的服务器组成 WSFC 集群，节点间每秒发送心跳包，判定服务器宕机、网络中断；
  2. 仲裁机制
     
    磁盘见证 / 文件共享见证 / 云见证防止脑裂；仅具备仲裁投票的节点可晋升为主副本；
  3. AG 侦听器 Listener（虚拟接入点）
     
    集群虚拟 IP + 虚拟名称，故障切换时自动漂移到新主副本；应用连接串无需修改，透明切换；
  4. AG 资源监控
     
    WSFC 持续监控每个副本数据库健康状态，任意副本数据库同步中断标记异常，满足故障转移条件则触发切换。

模块 2：事务日志同步全链路引擎（AG 最核心底层）

同步全程分为 4 步：日志捕获 → 日志传输 → 日志硬化（持久化） → 日志重做

1）日志捕获（主副本）

主库 DML/DDL 操作生成事务日志记录，写入本地 LDF 文件；
 
专用捕获线程持续扫描日志缓冲区，提取未同步日志块，封装成日志记录数据包，不等待事务提交即可预推送。

2）日志传输（TCP 长连接）

主副本与每个次要副本维持独立 TCP 加密通道，并行推送日志块；
 
支持两种传输模式：
  • 同步提交（Synchronous-commit）
  • 异步提交（Asynchronous-commit）

3）日志硬化（次要副本持久化）

次要副本接收日志块，写入本地 LDF 磁盘（硬化，Hardened），返回确认 ACK 给主副本。
  • 同步模式：主事务必须收到所有同步副本硬化 ACK，才向应用返回提交成功；RPO=0，无数据丢失；
  • 异步模式：主副本本地磁盘写完直接返回应用，后台异步推送日志，极端断网存在少量日志丢失风险。

4）日志重做（Redo，次要副本数据落地）

次要副本后台开启重做线程，读取本地已硬化的日志，在副本数据文件 MDF 上回放事务；
 
重做持续运行，因此同步 / 异步副本可提供只读访问（可读次要副本），这是 FCI 完全不具备的底层能力。

模块 3：两种提交模式底层差异

（1）同步提交（本地高可用零丢失）

事务完整链路：
 
应用提交 → 主库写入本地日志 → 推送日志至同步副本 → 副本落地磁盘 ACK 返回 → 主库返回成功给应用
 
底层代价：高并发写场景产生提交等待，增加主库写入延迟；
 
适用：同城双活，追求 RPO=0。

（2）异步提交（异地灾备）

事务完整链路：
 
应用提交 → 主库本地日志硬化 → 直接返回成功 → 后台异步推送日志到异地副本
 
底层优势：不影响主库写入性能；
 
风险：主副本机房整体损毁，未推送完成的日志永久丢失。

模块 4：故障转移底层执行机制

分为三种切换：自动故障转移、手动同步转移、强制异步转移

1. 自动故障转移（仅同步副本支持）

触发条件：主副本心跳失联、数据库不可用，且同步副本仲裁投票达标；
 
底层流程：
  1. WSFC 判定主副本离线，剥夺主副本投票权；
  2. 备用同步副本停止日志接收，完成所有本地日志重做；
  3. 将该副本数据库状态从 SECONDARY 切换为 PRIMARY；
  4. AG 侦听器虚拟 IP 漂移至新主副本；
  5. 应用重连 Listener，业务恢复。
     
    RTO 很短，仅重做未完成日志，无需重启完整 SQL 实例。

2. 强制故障转移（异步副本，灾难场景）

异地异步副本无完整日志，切换后丢失未同步事务；切换完成后需手动数据补齐。

四、可读次要副本底层原理（AG 独有特性）

次要副本日志重做与只读查询并行运行，底层隔离机制：
  1. 重做线程持续回放日志修改数据页；
  2. 只读查询读取数据页快照，重做操作不会阻塞读；
  3. 支持备份卸载：完整备份、日志备份可在次要副本执行，减轻主库 IO 压力；
  4. 分离读写业务：报表、统计、历史查询全部分流副本，提升整机资源利用率。

五、初始化副本底层两种机制

  1. 自动种子填充（Automatic Seeding）
     
    SQL 内部通过 TCP 流直接从主副本传输完整数据 + 日志文件，无需人工备份还原，适合快速部署；
  2. 手动备份还原
     
    传统方式：主库完整备份 + 日志备份，拷贝至次要副本还原，再加入 AG；适合大数据库、带宽不足场景。

六、AG 底层内置监控与健康检测

  1. 每个副本维护同步状态队列、未发送日志队列、未重做日志队列；
  2. DMV 动态管理视图暴露底层指标：
     
    sys.dm_hadr_database_replica_states、sys.dm_hadr_availability_replica_states；
  3. WSFC 资源每数秒检测数据库同步健康度，超过阈值标记未健康，阻断自动故障转移。

七、AG 架构底层固有优势（对比 FCI）

  1. 无共享存储、无 SCSI 磁盘独占锁，不存在存储单点故障；
  2. 多独立副本多份物理数据，天然数据冗余；
  3. 数据库粒度切换，单 AG 故障不影响其他业务库；
  4. 次要副本可持续提供只读、备份，硬件资源充分利用；
  5. 异步副本原生支持远距离异地机房灾备，架构成本远低于延伸集群 FCI。

八、AG 底层天生短板

  1. 依赖完整恢复模式，事务日志持续增长，需频繁日志备份截断；
  2. 同步提交模式带来主库写入延迟；
  3. 仅同步用户数据库，系统对象（登录、代理作业、证书）无自动同步机制，需外部运维脚本；
  4. 异步模式存在数据丢失风险；
  5. 日志传输、重做线程带来额外 CPU、网络 IO 开销。

九、一句话总结底层逻辑

AG 基于 WSFC 做集群调度，依靠事务日志流式复制在多台独立磁盘的 SQL 实例间维护多份数据库副本，通过同步 / 异步双模式兼顾本地高可用与异地灾备，次要副本支持并行只读查询，实现数据多副本冗余与读写分离。

 

故障转移群集（Failover Cluster Instances）和AlwaysOn是SQL Server中两种不同的高可用性解决方案。它们在实现高可用性的方式上有一些显著的区别：

  1. 故障转移群集（Failover Cluster Instances）：

    • 故障转移群集是一种基于 Windows Server 故障转移群集技术的解决方案，它使用共享存储并在主节点和辅助节点之间进行故障转移。
    • 故障转移群集中只有一个节点（通常为主节点）可以访问数据库，其他节点处于等待状态，只有在主节点发生故障时才会接管数据库服务。
    • 故障转移群集对于整个 SQL Server 实例进行故障转移，因此在节点切换时需要重新启动整个 SQL Server 实例。

  2. AlwaysOn：

    • AlwaysOn是SQL Server 2012及以后版本引入的一种高可用性和灾难恢复解决方案，它提供了多种不同的功能，包括AlwaysOn 可用性组和AlwaysOn 故障转移群集。
    • AlwaysOn 可用性组提供了数据库级别的高可用性，允许将一个或多个数据库组合成可用性组，并通过多个辅助节点实现数据复制和故障转移。
    • AlwaysOn 可用性组支持只读副本、自动故障检测和故障转移、自动数据库故障恢复等特性，可以实现更细粒度的故障转移和灾难恢复操作。

故障转移群集是一种基于 Windows Server 故障转移群集技术的解决方案，而AlwaysOn则是SQL Server提供的一整套高可用性和灾难恢复解决方案，包括可用性组和故障转移群集。

AlwaysOn 提供了更灵活、可扩展和细粒度的高可用性配置选项，适用于更复杂的业务需求。

 

posted @ 2024-03-26 21:19  suv789  阅读(431)  评论(0)    收藏  举报