一、Always On 技术概述
SQL Server的Always On可用性组是微软官方推荐的高可用性解决方案，它通过将多个数据库实例组合成一个逻辑单元，实现故障自动转移和手动切换功能。这个技术本质上是在Windows故障转移集群（WSFC）基础上实现的数据库级别高可用方案。
想象一下这样的场景：你的核心业务数据库突然宕机，而Always On就像个尽职的管家，能自动把服务切换到备用节点上，保证业务不中断。它最大的特点就是允许配置多个同步或异步的副本，这些副本可以分布在不同的物理位置。
二、手动切换配置实战
手动切换通常用于计划内的维护场景，比如服务器升级或硬件更换。下面我们通过PowerShell来演示如何配置手动切换（技术栈：SQL Server 2019 + PowerShell）：
# 导入SQL Server模块
Import-Module SqlServer
# 设置可用性组名称和副本信息
$agName = "AG_Demo"
$primaryServer = "SQL01"
$secondaryServer = "SQL02"
# 执行手动故障转移
Switch-SqlAvailabilityGroup `
-Path "SQLSERVER:\Sql\$primaryServer\Default\AvailabilityGroups\$agName" `
-NewPrimaryServer $secondaryServer `
-AllowDataLoss:$false `
-Confirm:$false
# 检查转移状态
Get-SqlAvailabilityGroup `
-Path "SQLSERVER:\Sql\$secondaryServer\Default\AvailabilityGroups\$agName" |
Select-Object Name, PrimaryReplicaServerName
这段代码做了三件事：
- 首先导入必要的SQL Server PowerShell模块
- 然后执行从SQL01到SQL02的手动切换
- 最后验证切换后的主副本信息
手动切换的关键是要确保所有同步副本都处于"SYNCHRONIZED"状态，否则可能会导致数据丢失。在实际操作前，建议先用以下T-SQL检查同步状态：
SELECT
ar.replica_server_name,
ars.synchronization_health_desc,
ars.synchronization_state_desc
FROM sys.availability_replicas ar
JOIN sys.dm_hadr_availability_replica_states ars
ON ar.replica_id = ars.replica_id
WHERE ar.group_id = (
SELECT group_id
FROM sys.availability_groups
WHERE name = 'AG_Demo'
)
三、自动故障转移配置详解
自动故障转移是Always On最强大的特性之一，它能在主副本不可用时自动切换到健康的备用副本。配置自动故障转移需要注意以下几点：
- 必须使用同步提交模式
- 需要配置故障转移条件
- 建议至少配置三个副本以防止脑裂
下面是通过T-SQL配置自动故障转移的示例：
-- 修改副本为自动故障转移模式
ALTER AVAILABILITY GROUP [AG_Demo]
MODIFY REPLICA ON 'SQL02' WITH (
FAILOVER_MODE = AUTOMATIC,
AVAILABILITY_MODE = SYNCHRONOUS_COMMIT
);
-- 设置故障转移条件
ALTER AVAILABILITY GROUP [AG_Demo]
SET (
REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 1,
DB_FAILOVER = ON,
DTC_SUPPORT = PER_DB
);
-- 验证配置
SELECT
replica_server_name,
failover_mode_desc,
availability_mode_desc
FROM sys.availability_replicas
WHERE group_id = (
SELECT group_id
FROM sys.availability_groups
WHERE name = 'AG_Demo'
);
自动故障转移的触发条件包括：
- 服务崩溃
- 操作系统宕机
- 硬件故障
- 网络隔离（需要配置租约超时）
四、测试方案设计与实施
测试是确保高可用性方案可靠的关键环节。下面介绍几种常用的测试方法：
- 手动故障转移测试：
# 模拟手动切换
Invoke-Sqlcmd -Query "ALTER AVAILABILITY GROUP [AG_Demo] FAILOVER;"
# 检查切换后状态
Invoke-Sqlcmd -Query "
SELECT
ag.name AS [AG Name],
ar.replica_server_name,
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
"
- 自动故障转移测试：
# 在主节点上停止SQL Server服务
Stop-Service -Name "MSSQLSERVER" -Force
# 等待30秒后检查当前主节点
Start-Sleep -Seconds 30
Invoke-Sqlcmd -ServerInstance $secondaryServer -Query "
SELECT @@SERVERNAME AS [Current Primary]
"
- 网络隔离测试：
# 在主节点上模拟网络中断
New-NetFirewallRule -DisplayName "Block_SQL_Port" -Direction Outbound -LocalPort 1433 -Action Block
# 检查集群状态
Get-ClusterResource | Where-Object {$_.State -ne "Online"} | Format-Table -AutoSize
# 记得清理规则
Remove-NetFirewallRule -DisplayName "Block_SQL_Port"
五、应用场景与技术选型
Always On适合以下典型场景：
- 关键业务系统需要99.9%以上的可用性
- 需要实现读写分离的OLTP系统
- 跨数据中心的灾备方案
与镜像和日志传送相比，Always On的优势在于：
- 支持多副本（最多8个）
- 提供可读辅助副本
- 集成Windows集群服务
- 更细粒度的监控
但也要注意它的局限性：
- 需要企业版授权
- 配置相对复杂
- 对网络延迟敏感（同步模式下）
六、常见问题排查
在实际运维中，可能会遇到以下典型问题：
- 故障转移失败： 检查WSFC仲裁配置和网络连接状态：
Test-Cluster -Node $primaryServer
Get-ClusterLog -Node $primaryServer -TimeSpan 5
- 同步延迟： 监控延迟情况：
SELECT
ag.name AS ag_name,
ar.replica_server_name,
db_name(drs.database_id) AS database_name,
drs.synchronization_state_desc,
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 ar.group_id = ag.group_id
- 脑裂情况处理：
# 强制仲裁
Stop-ClusterNode -Name $primaryServer -ForceQuorum
七、最佳实践与注意事项
根据多年运维经验，总结出以下最佳实践：
- 生产环境建议使用至少3个节点（1主+2同步副本）
- 跨机房部署时，考虑使用异步副本避免性能影响
- 定期测试故障转移流程（建议每季度一次）
- 监控关键指标：
- 同步延迟
- 副本健康状态
- 集群仲裁状态
特别注意：
- 自动故障转移后，原主节点恢复时会自动变为辅助副本
- 应用程序连接字符串需要配置MultiSubnetFailover=True
- 避免在业务高峰期执行手动切换
八、总结与展望
SQL Server Always On提供了企业级的高可用解决方案，通过合理配置手动和自动故障转移机制，可以显著提高系统可用性。随着SQL Server 2022的发布，Always On功能进一步增强，包括与Kubernetes的深度集成和更智能的故障预测能力。
对于DBA来说，掌握Always On的配置和运维是必备技能。建议从测试环境开始，逐步熟悉各种故障场景的处理方法，最终在生产环境中实现真正的高可用架构。
评论