一、从传统镜像到Always On：为什么我们需要升级？

曾经，数据库镜像是SQL Server的"救命稻草"。当主库挂掉时，就像断电时的手电筒，镜像库瞬间接管服务。但如今，总有人问："为什么微软要推出Always On可用性组？是不是镜像不够用了？"

真实案例更直观：某电商平台的订单库使用镜像方案三年，遇到双十一大促时，故障转移需要人工干预，导致30分钟服务中断。而迁移到Always On后，自动化切换时间缩短至10秒内，还能实现读写分离负载均衡。

示例1：传统数据库镜像的核心配置脚本

-- 主库配置
ALTER DATABASE OrderDB SET PARTNER = 'TCP://MirrorServer:5022';
GO

-- 镜像库配置（见证服务器可选）
ALTER DATABASE OrderDB SET PARTNER = 'TCP://PrincipalServer:5022';
GO

-- 手动故障转移（需要管理员介入）
ALTER DATABASE OrderDB SET PARTNER FAILOVER;
GO

（注释：通过5022端口建立镜像会话，见证服务器用于自动故障转移，但实际运维中常因网络抖动导致误判）

二、Always On可用性组深度拆解

2.1 新一代高可用架构的秘密武器

Always On的核心是可用性组（Availability Group），支持最多8个同步副本。想象一个智能交通系统：主副本是信号灯控制中心，多个次级副本就像备用控制站，能自动接管且数据零丢失。

示例2：创建可用性组的核心步骤

# 通过PowerShell自动创建可用性组
New-SqlAvailabilityGroup `
-Name AG_OrderDB `
-Path "SQLSERVER:\SQL\PrimaryServer\DEFAULT" `
-AvailabilityDatabase "OrderDB" `
-PrimaryReplica "PrimaryServer" `
-SecondaryReplica "SecondaryServer1","SecondaryServer2" `
-AutomatedBackupPreference Secondary `
-FailureConditionLevel OnServerDown

（注释：FailureConditionLevel参数定义了自动故障触发条件，比镜像更灵活的故障检测机制）

2.2 读写分离的实战应用

当报表查询拖慢OLTP性能时，ReadOnly路由能像交警一样智能分流：

示例3：配置只读路由列表

ALTER AVAILABILITY GROUP [AG_OrderDB]
MODIFY REPLICA ON 'SecondaryServer1' 
WITH (SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY));

ALTER AVAILABILITY GROUP [AG_OrderDB] 
MODIFY REPLICA ON 'SecondaryServer1'
WITH (SECONDARY_ROLE (READ_ONLY_ROUTING_URL = 'TCP://SecondaryServer1:1433'));

（注释：应用程序连接字符串添加ApplicationIntent=ReadOnly即可自动路由到只读副本）

三、混合部署期间的生存指南

3.1 双架构共存的风险地图

当用户忘记删除旧镜像端点时，就像同时在两个泳道游泳，容易引发灾难：

示例4：监控混合环境的PowerShell脚本

# 检测数据库状态冲突
Get-DbaDatabase -SqlInstance PrimaryServer | 
Where-Object {$_.IsMirroringEnabled -and $_.AvailabilityGroupName} |
Format-Table Name, AvailabilityGroupName, MirroringStatus

（注释：部分数据库同时启用镜像和可用性组时，会导致日志传送链断裂）

3.2 数据同步的"双保险"模式

迁移过程中，如何保证数据连续性？试试日志传送+镜像的混合方案：

示例5：双通道同步配置

-- 主库同时启用镜像和日志传送
EXEC sp_add_log_shipping_secondary 
@primary_server = N'PrimaryServer',
@secondary_server = N'SecondaryServer1';

EXEC sp_add_log_shipping_secondary 
@primary_server = N'PrimaryServer',
@secondary_server = N'SecondaryServer2';

（注释：此方案适用于关键业务系统，但会增加主库I/O压力，需严格监控日志生成速率）

四、技术选型的决策树

4.1 传统镜像是"稳妥的老管家"

适用场景：

  • 预算有限的部门级应用
  • 已有Windows 2008 R2系统
  • 对自动故障转移要求不高

经典案例：某医院影像归档系统，每天20:00-6:00维护窗口可接受人工切换。

4.2 Always On是"智能机器人"

核心优势：

  • 多副本自动负载均衡
  • 并行数据库恢复（速度比镜像快4倍）
  • 在线页面修复（自动修复损坏数据页）

真实效果：某证券交易所系统切换后，年度故障时间从8小时缩短至47秒。

五、分阶段迁移策略

  1. 镜像优先阶段：所有新系统优先配置Always On
  2. 并行测试阶段：关键业务双架构运行至少两周
  3. 分级淘汰阶段：按业务优先级逐步下线镜像

示例6：数据一致性验证脚本

-- 使用CHECKSUM验证数据一致性
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'checksum', 1;
RECONFIGURE;

DBCC CHECKDB('OrderDB') WITH PHYSICAL_ONLY, NO_INFOMSGS;

（注释：物理检查后，需要逻辑比对：通过HASHBYTES函数比较随机采样数据）

六、必须安装的性能仪表盘

  • 副本同步延迟监控（阈值建议<5秒）
  • 日志发送队列监控（预警值>1000条）
  • 自动故障转移历史统计

示例7：动态管理视图监控

SELECT 
    ag.name AS AGName,
    ar.replica_server_name,
    drs.database_id,
    drs.log_send_queue_size,
    drs.redo_queue_size 
FROM sys.dm_hadr_database_replica_states drs
JOIN sys.availability_replicas ar ON drs.replica_id = ar.replica_id
JOIN sys.availability_groups ag ON ag.group_id = ar.group_id

（注释：log_send_queue_size持续增长可能预示网络带宽瓶颈）

七、成功案例的DNA解码

某省级社保平台迁移日志：

  1. 准备阶段（2周）：网络带宽从1G升级到10G
  2. 测试阶段（3天）：模拟30种故障场景
  3. 实施阶段（凌晨1点-3点）：采用滚动升级方式
  4. 回退方案：预先生成镜像会话但暂不激活

成果：年度维护时间缩短60%，报表查询响应速度提升300%。

八、总结与展望

传统镜像像机械手表——精确可靠但功能单一；Always On则像智能手表——功能全面但需要更专业的维护。当选择混合部署时，就像同时佩戴两块手表，需要严格的时间校准机制。未来发展方向已经明确：智能化的全自动容灾将成为标配，但掌握旧技术仍然是应对突发状况的底气。