2. SQL Server高可用与灾难恢复技术全景

SQL Server 的高可用（HA）与灾难恢复（DR）并不是单一功能，而是一组在恢复目标（RPO/RTO）、故障域、数据副本方式、自动化程度上差异很大的技术集合。做业务连续性验证时，第一步不是急着搭环境，而是先判断“这项技术到底保护什么、失效时会发生什么、验证时该盯哪些证据”。本节把 Always On 可用性组、故障转移群集实例（FCI）、日志传送、数据库镜像、复制与备份恢复放在同一张全景图上，逐一说明适用场景与验证关注点。

一、先建立判断坐标：RPO、RTO 与故障域

RPO（恢复点目标）衡量“允许丢多少数据”，RTO（恢复时间目标）衡量“允许停多久”。同步提交的副本 RPO 接近 0，但会受网络往返延迟影响；异步提交不阻塞主库，RPO 取决于发送队列积压量。故障域则决定技术能否覆盖：单机磁盘故障、单实例进程崩溃、整台服务器宕机、机房断电、区域级灾难，属于不同层级。验证时要把每项技术映射到它能覆盖的故障域，否则会出现“以为有保护、实际没覆盖”的盲区。

二、六类技术的定位与验证关注点

Always On 可用性组（AG）：以数据库为保护单位，通过同步/异步提交把事务日志传送到多个副本，支持自动或手动故障转移，并可配置只读辅助副本分担查询。适用场景是核心 OLTP 库需要秒级 RTO、多副本读扩展。验证关注点：副本同步状态（SYNCHRONIZED/SYNCHRONIZING）、发送队列与重做队列大小、自动故障转移条件是否满足、监听器切换后连接是否自动重定向、只读路由是否生效。

故障转移群集实例（FCI）：以整个实例为保护单位，多个节点共享同一份存储（共享磁盘或 Storage Spaces Direct），实例在节点间漂移。它保护的是实例级故障，不提供数据副本，因此无法防止存储损坏。验证关注点：仲裁配置与投票节点、共享存储健康、节点故障时实例漂移时间、漂移后登录名/作业/链接服务器等实例级对象是否完整。

日志传送：主库做日志备份，通过文件共享传到辅助服务器并还原，延迟通常为分钟级。适合跨版本、跨平台、低成本的 DR 场景，也可作为 AG 的补充。验证关注点：备份作业、复制作业、还原作业是否连续成功、还原延迟（restore latency）、是否存在未还原的日志文件积压、辅助库是否处于 RESTORING 状态。

数据库镜像：以数据库为单位，同步或异步把日志传送到镜像服务器，支持自动故障转移（需见证服务器）。该功能自 SQL Server 2012 起被标记为弃用，新项目应优先选 AG，但存量系统仍需验证。关注点：镜像状态（SYNCHRONIZED）、见证服务器连通性、主体与镜像角色切换、端点加密与认证。

复制：以对象/行为单位分发数据，分快照、事务、合并等类型，适合读写分离、报表库、多站点数据汇聚。它不是高可用方案，因为复制延迟和冲突处理不保证 RPO。验证关注点：分发代理与日志读取代理是否持续运行、未分发命令数、订阅端数据一致性抽样、冲突与跳过的事务。

备份恢复：最后一道防线，也是所有 HA 技术的基础。完整恢复模式下配合日志备份可实现时间点恢复。验证关注点：备份链是否连续（完整+差异+日志）、RESTORE VERIFYONLY 是否通过、实际还原演练耗时、还原后 DBCC CHECKDB 是否通过。

三、验证关注点如何落到可观测指标

把“验证关注点”变成可执行动作，关键是找到对应的系统视图与计数器。例如 AG 可用 sys.dm_hadr_database_replica_states 查看 log_send_queue_size（发送队列 KB）和 redo_queue_size（重做队列 KB），二者持续增长说明辅助副本跟不上；日志传送可查 msdb.dbo.log_shipping_monitor_primary 与 log_shipping_monitor_secondary 的 last_restored_file 和 restore_latency；复制可查 sys.dm_repl_tranhash 或分发库中的未分发命令数。验证报告应记录“指标名 + 采集时刻 + 阈值 + 实测值”，而不是只写“检查正常”。

四、组合使用与选择建议

真实生产环境往往是组合方案：FCI 保护实例级故障，AG 在其上提供数据库级副本与读扩展，日志传送作为跨站点兜底，备份恢复作为最终防线。选择时按以下顺序判断：先明确 RPO/RTO 与故障域，再看是否需要自动故障转移，最后评估成本与运维复杂度。若 RPO 要求接近 0 且需要自动切换，优先 AG 同步提交；若跨版本、跨平台或预算有限，日志传送更现实；若只是报表分流，复制或 AG 只读副本即可，不必上自动故障转移。

五、验证记录示例

下表给出一个可直接套用的验证记录片段，字段按本节技术全景设计，覆盖技术、故障域、观测指标、阈值与结论。

把这张全景图作为验证工程的起点：每项技术先定位它保护的故障域与 RPO/RTO 能力，再选取对应观测指标，最后用一次真实切换或还原演练来证明结论。只有“指标可采集、切换可复现、数据可核对”，业务连续性验证才算真正闭环。