SQL Server 高可用容灾备份方案：Mirror 和 AlwaysOn

当前位置：点晴教程→知识管理交流 →『技术文档交流』

admin

2026年3月21日 7:26 本文热度 20

Oracle 有Dataguard，SQL Server 同样有自己的容灾方案：Mirror 和 AlwaysOn。

因为技术迭代，2012版本之前，SQL Server 只支持Mirror（镜像）方式做容灾。2012及以后版本支持AlwaysOn，（Mirror标记为将被移除的功能，其实还能使用）。

SQL Server Mirror：曾经的主流方案

✔ 它是什么？

Database Mirroring（数据库镜像）是 SQL Server 早期的高可用方案。

核心机制：

主库（Principal）

镜像库（Mirror）

可选见证（Witness，实现自动切换）

✔ 优点（为什么当年很多人用）

配置相对简单

切换速度快

同步模式下基本无数据丢失

成本较低（标准版也能用）

❌ 缺点（也是它被淘汰的原因）

1️⃣ 粒度太“细”（数据库级）

👉 一个实例有10个库，就要配10套镜像

2️⃣ 不支持读扩展

备库基本不能用来分担读压力

资源利用率低

3️⃣ 已被官方“边缘化”

从 SQL Server 2012 开始：

👉Mirror 被标记为“将被移除的功能”

AlwaysOn：企业级高可用方案

✔ 它是什么？

AlwaysOn Availability Groups（可用性组）是 SQL Server 主推的HA/DR方案。

核心能力：

一主多从

多副本同步 / 异步

组级切换（多个数据库一起切）

✔ 核心优势（重点看这几个）

1️⃣ 业务级切换（不是单库）

👉 多个数据库可以打包成一个“可用性组”

意味着：

应用相关数据库可以一起切换

不会出现“有的库切了，有的没切”

2️⃣ 支持读写分离

主库负责写

从库可以用来查询

👉真正实现资源利用最大化

3️⃣ 支持多副本（更强容灾）

本地高可用（同城）

异地灾备（异步复制）

👉 可以构建“两地三中心”架构

4️⃣ 自动故障转移更成熟

健康检测更完善

故障判断更智能

❌ 需要注意的成本

1️⃣ 版本要求

👉 完整功能需要企业版（Enterprise Edition）

2️⃣ 架构复杂度更高

依赖 Windows Failover Cluster（WSFC）

配置比 Mirror 更复杂

Mirror vs AlwaysOn：核心对比

对比项	Mirror	AlwaysOn
保护粒度	单数据库	数据库组
是否支持多库一致切换	❌	✅
是否支持读扩展	❌	✅
副本数量	1个镜像	多副本
自动切换	有（依赖见证）	更成熟
架构复杂度	低	高
未来支持	❌（逐步淘汰）	✅ 主流方案