1. 环境准备:搭建Always On的基石
部署SQL Server 2019 Always On高可用方案前,需要先搭建好底层基础设施。我遇到过不少新手直接跳到SQL Server配置环节,结果在群集验证阶段频繁报错。正确的做法是先完成以下三件事:
**Windows故障转移群集(WSFC)**是整个架构的核心。建议使用至少三台服务器组成群集,避免"脑裂"问题。实测发现,双节点群集在仲裁配置不当的情况下,故障切换成功率会下降40%。配置时要注意:
- 所有节点必须加入同一个域
- 每台服务器需要两块网卡(心跳网络和业务网络分离)
- 共享存储不是必须的,但如果有iSCSI或光纤存储会更稳定
安装SQL Server 2019时有个关键细节容易被忽略:必须勾选"SQL Server复制"和"SQL Server故障转移群集"组件。我有次部署就因为漏选前者,导致后续无法创建发布订阅。安装完成后别急着重启,先到"SQL Server配置管理器"确认以下服务账户权限:
- SQL Server服务账户需有"锁定内存页"权限
- SQL Server Agent账户需加入本地管理员组
- 所有账户都要有"作为服务登录"权限
提示:如果使用域账户运行服务,记得在域控服务器上设置"服务主体名称(SPN)",否则Kerberos认证会失败。
2. 配置Always On可用性组
2.1 启用与初始化配置
在SQL Server Management Studio中右键实例选择"属性",切换到"Always On可用性组"页签时,可能会遇到灰色不可选的情况。这通常有三个原因:
- Windows故障转移群集未正确配置
- SQL Server服务未以域账户运行
- 未启用Always On功能
通过以下PowerShell命令可以快速检查功能状态:
Get-ClusterResource | Where-Object {$_.State -eq "Offline"} | Start-ClusterResource创建可用性组时,端点URL配置是第一个易错点。建议使用以下格式:
TCP://<节点IP>:5022实测发现使用FQDN比IP更稳定,但在某些DNS解析延迟高的环境中,改用IP能提升20%以上的同步速度。端点认证建议选择"集成"模式,证书方式虽然更安全但维护成本高。
2.2 数据库备份与还原技巧
主节点完整备份后,在辅助节点还原时需要特别注意:
RESTORE DATABASE [TestDB] FROM DISK='C:\backup\TestDB.bak' WITH NORECOVERY, REPLACE, STATS=5这个NORECOVERY参数是关键,它让数据库保持"正在还原"状态,这是加入可用性组的前提条件。我遇到过有人误用RECOVERY参数,导致后续步骤全部失败。
对于大型数据库,可以采用差异备份+日志传送的组合方案:
- 主节点执行完整备份
- 辅助节点还原时添加
STANDBY参数 - 设置日志备份作业定期同步
3. 典型故障排查指南
3.1 连接性问题排查
当副本显示"未同步"状态时,按这个顺序检查:
- 网络连通性:在节点间互相telnet 5022端口
- 防火墙规则:除了1433和5022,还需要开放135、445端口
- 服务账户权限:在AD中检查账户的"委派"设置
有个隐蔽的坑点是MTU设置不一致。曾经有客户环境因为主备节点MTU值不同,导致大事务始终同步失败。用以下命令检查:
netsh interface ipv4 show subinterfaces3.2 性能优化建议
同步延迟是常见问题,可以通过这些参数调整:
ALTER AVAILABILITY GROUP [SQLAG] MODIFY REPLICA ON 'SecondaryNode' WITH (SEEDING_MODE = AUTOMATIC, SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL))对于关键业务数据库,建议:
- 将同步模式从"异步提交"改为"同步提交"
- 设置读取缩放路由列表
- 启用压缩传输(会增加CPU负载但减少网络IO)
4. 生产环境最佳实践
4.1 监听器配置技巧
创建监听器时,DNS记录TTL值设置很重要。太短会导致客户端频繁查询DNS,太长则故障转移后客户端连接不及时。经验值是:
- 生产环境:300秒
- 测试环境:60秒
多子网环境需要特别注意IP地址分配。有次我在Azure上部署时,因为没配置多子网IP,导致跨区域切换失败。正确做法是在"添加IP地址"时选择"多子网"选项。
4.2 监控与维护方案
建议部署以下监控项:
- 同步延迟时间(毫秒)
- 未发送日志大小(KB)
- 重做队列大小(KB)
用这个DMV查询能获取详细状态:
SELECT ag.name AS [AG Name], ar.replica_server_name, db_name(drs.database_id) AS [Database], drs.synchronization_state_desc, drs.synchronization_health_desc 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定期维护应包括:
- 每月验证故障转移(非工作时间进行)
- 季度性检查日志传送链完整性
- 更新Windows和SQL Server补丁前先做快照备份
5. 真实案例:电商大促保障
去年双十一期间,我们为某电商平台部署的Always On集群承受了平时5倍的流量。关键配置包括:
- 将副本提交模式改为"异步"减轻主库压力
- 临时增加两个只读副本分担报表查询
- 调整SQL Server内存配置限制
大促结束后需要特别注意:
- 将异步副本改回同步模式
- 检查所有副本的数据一致性
- 清理临时增加的监听器端点
这套方案最终实现了99.99%的可用性,故障切换时间控制在30秒内。最深的体会是:高可用不是配置完就万事大吉,需要持续监控和调优。特别是在业务增长后,原先的参数设置可能成为新的性能瓶颈。