1. 项目概述为什么我们需要AlwaysOn在数据库运维的日常里最怕听到的不是“性能有点慢”而是“数据库挂了”。对于像SQL Server这样承载核心业务数据的系统停机往往意味着业务中断、数据丢失和真金白银的损失。传统的备份恢复、日志传送或者镜像技术虽然能在一定程度上提供数据保护但在故障切换的自动化、读写分离的灵活性以及对应用透明性方面总有些力不从心。这就像给汽车只备了一个备胎爆胎时你得自己停车、动手更换耽误时间不说操作还容易出错。SQL Server AlwaysOn可用性组AlwaysOn Availability Groups简称AG的出现就是为了解决这个痛点。它不是一个独立的新功能而是将数据库镜像和故障转移集群的核心思想进行了深度融合与升华。你可以把它理解为一个“数据库级别的集群”。它允许你将一组用户数据库称为“可用性数据库”作为一个整体在多个SQL Server实例称为“副本”之间进行同步或异步的数据复制并提供一个统一的虚拟网络名称侦听器供应用程序连接。当主副本发生故障时系统可以自动或手动将服务快速切换到某个健康的辅助副本整个过程对前端应用几乎是透明的最大程度地保障了业务连续性。我经历过从数据库镜像到AlwaysOn的迁移也处理过不少AG环境下的故障。实话实说搭建AlwaysOn的初始配置步骤并不算特别复杂但其中涉及的原理、网络、存储、权限等细节任何一个环节的疏忽都可能为日后埋下大坑。这篇文章我就以一个老DBA的视角带你从零开始手把手搭建一套高可用的AlwaysOn环境并重点分享那些官方文档里不会写但实践中一定会遇到的“坑”和技巧。2. 搭建前的核心设计与环境规划搭建AlwaysOn不是简单地运行几个向导前期的规划设计决定了整个架构的稳定性和可维护性。盲目动手后期很可能要推倒重来。2.1 架构选型到底需要几个节点这是第一个要回答的问题。AlwaysOn的基本架构需要至少两个SQL Server实例节点。但实践中我强烈推荐三节点起步的配置。两节点模式一个主副本一个辅助副本。这是最低配置能提供基本的故障转移和数据保护。但它的致命缺陷在于“法定票数”问题。在Windows Server故障转移集群WSFC中需要多数节点在线才能维持集群存活。两个节点时任意一个节点离线集群就会因为无法形成多数2个中的1个不是多数而停止服务即使另一个节点本身是健康的。为了解决这个问题你需要引入一个“文件共享见证”或“磁盘见证”作为第三个投票成员。所以两节点架构本质上还是依赖了第三个外部角色。三节点模式这是生产环境的黄金标准。例如配置两个同步提交副本一个主一个辅助用于高可用第三个节点配置为异步提交副本可以部署在异地机房用于灾难恢复也可以只用于报表查询。三节点天然解决了法定人数问题架构更健壮。我的建议除非是预算极其有限的测试环境否则生产环境直接规划三节点。两个节点放在主数据中心同步提交第三个节点放在另一个机房异步提交。这样既满足了本地高可用也实现了跨机房容灾。2.2 基础设施准备清单在安装SQL Server之前以下基础设施必须就绪。很多搭建失败的问题根源都在这里。Windows Server故障转移集群WSFCAlwaysOn AG依赖于WSFC来提供底层的节点管理和故障检测。这意味着你的所有SQL Server节点必须先加入同一个WSFC。操作系统所有节点需使用相同或兼容版本的Windows Server如全部是Windows Server 2019/2022。网络每个节点至少需要两块网卡一块用于公共网络业务访问一块用于私有网络集群心跳和数据库同步。务必为私有网络配置独立的IP段并关闭该网卡的DNS注册、NetBIOS等无关功能确保心跳流量纯净、低延迟。域环境所有节点必须加入同一个Active Directory域。运行SQL Server服务的账户通常是域账户需要在每个节点上拥有“管理员”权限。存储特别注意与故障转移集群不同AlwaysOn AG的数据文件并不需要共享存储如SAN。每个节点使用自己的本地存储来存放数据库文件。这消除了传统的共享存储单点故障是架构上的一大进步。SQL Server实例准备版本必须是SQL Server Enterprise Edition或Developer Edition仅用于开发测试。Standard版从SQL Server 2016 SP1开始支持基础可用性组功能有限。安装在每个节点上安装相同版本的SQL Server。在安装过程中或安装后需要启用“AlwaysOn可用性组”功能。可以通过SQL Server配置管理器来启用。服务账户为SQL Server服务和SQL Server代理服务配置同一个域账户。这个账户将被自动授予必要的集群权限。端点与防火墙AlwaysOn使用一个专用的数据库镜像端点进行副本间的通信。默认使用TCP端口5022。确保所有节点防火墙开放了5022端口的入站规则并且SQL Server的镜像端点状态是“已启动”。2.3 权限与账户的“坑”权限问题是新手最容易栽跟头的地方。很多错误提示模糊根本原因就是账户权限不足。集群服务账户创建WSFC的账户必须是域中具有管理员权限的账户。SQL Server服务账户这个账户需要是域用户。在每个节点本地管理员组中。在AD中对其自身计算机对象以及可能涉及的其他节点计算机对象拥有“读取”和“写入”权限通常加入本地管理员组即可满足。拥有对集群名称对象CNO和后续创建的侦听器名称对象VCO的“创建计算机对象”权限。这一点至关重要通常的做法是在AD中预先创建一个OU组织单元然后委派这个OU的“创建和删除计算机对象”权限给SQL Server服务账户。这样在配置侦听器时账户就能自动在AD中注册DNS记录。执行搭建操作的账户你用来登录SSMSSQL Server Management Studio并进行AG配置的账户最好是域管理员或具有同等权限的账户避免中途因权限不足而卡住。实操心得我习惯在搭建前专门在AD中创建一个OU比如叫“SQL_Cluster_Objects”然后严格按照上述要求进行权限委派。并且在每个节点上都用whoami /all命令检查当前登录上下文用net localgroup administrators确认服务账户已在本地管理员组。花10分钟确认权限能省下几小时排错的时间。3. 分步搭建实操详解假设我们已经准备好了三台服务器SQLNode01,SQLNode02,SQLNode03均已加入域contoso.com并完成了WSFC的搭建集群名为SQLWSFC。SQL Server实例已安装并启用了AlwaysOn功能。3.1 第一步初始化数据库与完整备份AlwaysOn AG是基于数据库日志传送的原理工作的。因此主副本上的数据库必须处于完整恢复模式并且至少做过一次完整备份。-- 在主副本SQLNode01上执行 USE master; GO -- 创建示例数据库或选择已有的业务数据库 CREATE DATABASE [AGDemoDB]; GO -- 将数据库恢复模式设置为“完整” ALTER DATABASE [AGDemoDB] SET RECOVERY FULL; GO -- 执行一次完整备份这是初始化辅助副本数据的基础 BACKUP DATABASE [AGDemoDB] TO DISK ND:\Backup\AGDemoDB_Full.bak WITH FORMAT, INIT, COMPRESSION; GO -- 执行一次事务日志备份在完整备份后立即进行 BACKUP LOG [AGDemoDB] TO DISK ND:\Backup\AGDemoDB_Log.trn WITH INIT, COMPRESSION; GO为什么必须是完整备份因为辅助副本需要通过还原这个完整备份加上后续的日志备份来同步数据。简单恢复模式下的数据库不会产生事务日志备份因此无法用于AlwaysOn。3.2 第二步通过SSMS向导创建可用性组这是最直观的搭建方式。在SSMS中连接到主副本实例SQLNode01。在“对象资源管理器”中右键点击“AlwaysOn高可用性”-“可用性组”-“新建可用性组向导”。指定名称输入可用性组的名称如AG_Demo。选择数据库勾选我们刚才创建的AGDemoDB。系统会自动检查数据库是否符合条件完整恢复模式、已有完整备份、处于联机状态等。指定副本添加SQLNode02和SQLNode03作为副本。故障转移模式对于SQLNode02选择“同步提交”。这意味着主副本必须等待该副本的日志硬化确认后才能提交事务保证了数据的零丢失适用于自动故障转移。对于SQLNode03异地可以选择“异步提交”优先保证主副本性能允许少量数据丢失风险。可读辅助副本可以设置为“是”允许在辅助副本上执行只读查询实现读写分离负载。这里我们可以将SQLNode02和SQLNode03都设置为“是”。自动故障转移在SQLNode01和SQLNode02之间勾选。这意味着这两个同步提交的副本可以相互自动切换。SQLNode03是异步提交不能参与自动故障转移。端点配置通常使用默认的镜像端点端口5022确保之前防火墙已开放。备份首选项设置备份在哪个副本上执行。为了减轻主副本压力通常选择“首选辅助副本”。侦听器配置这是给应用程序连接的虚拟名称。创建一个侦听器例如AGListener。指定一个虚拟IP如192.168.1.100并指定端口默认1433如果与实例默认端口冲突则需修改。网络模式选择“静态IP”并为每个子网指定IP地址如果你的节点分布在多个网段。选择数据同步选择“完整”。向导会自动将主副本的备份文件共享出来并在辅助副本上执行还原操作。你需要提供一个所有副本服务器账户都能访问的网络共享路径如\\SQLNode01\SQLBackup。确保权限正确。验证与创建向导会进行最终验证通过后点击“完成”。系统会依次执行创建端点、还原数据库、加入副本、创建侦听器等操作。3.3 第三步验证与基本测试创建完成后在SSMS中展开“AlwaysOn高可用性”可以看到新建的可用性组。绿色箭头表示同步状态正常。进行基本测试连接测试尝试使用侦听器名称AGListener连接数据库。无论连接被路由到哪个副本你都应该能成功连接并看到AGDemoDB。只读路由测试在应用程序连接字符串中可以添加ApplicationIntentReadOnly参数。使用这个连接字符串通过侦听器连接应该会被自动路由到我们设置为可读的辅助副本SQLNode02或SQLNode03从而减轻主库的查询压力。手动故障转移测试在SSMS中右键点击可用性组 - “故障转移”。选择一个目标副本如同步提交的SQLNode02。跟随向导完成。观察业务连接是否中断会有短暂中断然后恢复。主副本角色会切换到SQLNode02。4. 核心运维与深度解析搭建成功只是开始日常运维和深度理解才是保障稳定的关键。4.1 同步状态与数据流动监控理解AG的几种同步状态是排错的基础。SYNCHRONIZED同步提交副本的理想状态。主副本上的每个事务都会等待辅助副本将日志写入磁盘硬化并返回确认后才向客户端提交。数据零丢失。SYNCHRONIZING通常出现在初始数据同步、网络延迟较大或辅助副本性能跟不上时。主副本不需要等待辅助副本确认即可提交存在数据丢失风险。对于异步提交副本这可能是一种常态。NOT SYNCHRONIZING副本未连接或连接失败。需要立即检查网络、端点、防火墙或实例状态。监控方法-- 查询每个数据库在每个副本上的同步状态和滞后情况 SELECT ag.name AS AG_Name, ar.replica_server_name, adc.database_name, drs.synchronization_state_desc, drs.synchronization_health_desc, drs.log_send_queue_size, -- 未发送的日志量KB drs.log_send_rate, -- 日志发送速率KB/秒 drs.redo_queue_size, -- 待重做的日志量KB drs.redo_rate -- 重做速率KB/秒 FROM sys.dm_hadr_database_replica_states drs JOIN sys.availability_databases_cluster adc ON drs.group_database_id adc.group_database_id JOIN sys.availability_groups ag ON ag.group_id drs.group_id JOIN sys.availability_replicas ar ON drs.replica_id ar.replica_id ORDER BY ag.name, adc.database_name, ar.replica_server_name;关注log_send_queue_size和redo_queue_size。如果这两个值持续增长说明同步出现了瓶颈可能是网络带宽不足、辅助副本磁盘I/O慢或CPU资源紧张。4.2 侦听器Listener的工作原理与陷阱侦听器是AG的“门面”但它本身不承载任何数据流量。它的本质是一个在WSFC中注册的虚拟网络名称VNN和虚拟IPVIP。连接路由客户端连接侦听器时WSFC的集群服务会根据当前的主副本是哪个节点将这个VIP动态绑定到该节点的物理网卡上。所有网络流量实际上还是直接到达主副本服务器。故障转移过程当故障转移发生时WSFC会将VIP从旧主节点解绑并在新主节点上重新绑定。同时更新DNS缓存TTL通常很短。这个过程会导致现有的TCP连接中断客户端需要重连。这就是为什么应用程序必须具备连接重试机制。多子网环境如果副本分布在不同的IP子网如跨机房你需要为侦听器在每个子网都配置一个IP。现代ADO.NET、JDBC等驱动程序支持MultiSubnetFailoverTrue连接参数可以加速跨子网连接时的DNS解析显著减少故障转移后的连接时间。常见陷阱DNS问题侦听器依赖DNS解析。确保客户端能正确解析侦听器名称且DNS记录的TTL设置合理建议300秒或更短。Kerberos SPN如果使用Windows身份验证在故障转移后连接到新主副本可能需要Kerberos票据。确保为SQL Server服务账户正确注册了SPN同时也要为侦听器名称注册SPN。这是一个高级但常见的问题错误表现为连接时出现“登录失败”或“找不到目标主体名称”。# 为侦听器注册SPN在域控制器或具有足够权限的机器上执行 setspn -S MSSQLSvc/AGListener.contoso.com:1433 CONTOSO\SQLServiceAccount setspn -S MSSQLSvc/AGListener:1433 CONTOSO\SQLServiceAccount4.3 备份策略与维护作业在AG环境中备份可以卸载到辅助副本执行这是一大优势。备份首选项在AG属性中设置。通常选择“首选辅助副本”这样备份作业会在可用的辅助副本上运行。如果所有辅助副本都不可用则回退到主副本。维护作业索引重建、统计信息更新等重量级操作如果放在主副本执行会产生大量日志并同步到所有辅助副本可能造成同步延迟。一个优化思路是在可读的辅助副本上执行DBCC CHECKDB等一致性检查或者考虑使用ONLINE ON选项重建索引以减少阻塞。但要注意某些维护操作如修改表结构必须在主副本进行。日志清理在AG中事务日志只有在所有辅助副本都已完成日志重做后才能在主副本上被截断。如果某个辅助副本断开连接或重做速度慢会导致主副本的日志文件不断增长。监控redo_queue_size并及时处理慢的辅助副本至关重要。5. 典型故障排查与实战经验即使规划得再好生产环境也总会遇到问题。以下是几个我亲身踩过的坑和解决方法。5.1 故障转移失败或时间过长现象手动或自动故障转移时长时间卡在“正在解决当前状态”或直接失败。排查思路检查集群健康在故障转移集群管理器中检查SQLWSFC集群是否健康所有节点网络是否正常仲裁配置是否正确。使用Get-ClusterNode和Test-ClusterPowerShell命令进行深度检查。检查SQL Server资源在集群管理器中找到“角色”下的AG资源组。检查SQL Server网络名称、SQL Server代理、可用性组资源等是否都处于“联机”状态。尝试右键点击资源组“将此服务或应用程序移动到另一个节点”看是否能手动移动。分析SQL Server错误日志和Windows系统日志故障转移的详细步骤和错误信息会记录在这里。重点关注错误号。常见原因网络波动私有心跳网络不稳定导致集群误判节点离线。资源依赖故障例如侦听器IP地址资源无法在新节点上联机可能是因为IP地址冲突或网络配置问题。同步状态不佳如果辅助副本的同步状态不是SYNCHRONIZED则不允许自动故障转移同步提交模式下。权限问题SQL Server服务账户在新节点上权限不足无法访问数据库文件或启动服务。5.2 同步延迟Log Send/Redo Queue堆积现象监控中发现log_send_queue_size或redo_queue_size持续很高。分析与解决队列类型可能原因排查与解决方向日志发送队列大(log_send_queue_size)1.网络带宽瓶颈主副本生成日志的速度超过了网络传输能力。2.主副本磁盘I/O瓶颈日志文件写入慢导致发送慢。3.辅助副本接收慢网络包处理慢。1. 监控网络利用率如使用PerfMon计数器Network Interface\Bytes Total/sec。2. 检查主副本日志磁盘的磁盘延迟Avg. Disk sec/Write。3. 考虑压缩AlwaysOn流量在端点或AG属性中设置但会增加CPU开销。重做队列大(redo_queue_size)1.辅助副本磁盘I/O瓶颈日志文件写入或数据文件写入慢。2.辅助副本CPU资源不足重做进程REDO Thread是单线程的如果主库并发事务极高辅助库可能跟不上。3.辅助副本上有阻塞在可读辅助副本上运行的长时间只读查询可能持有锁阻塞了重做操作。1. 检查辅助副本数据/日志磁盘的磁盘延迟。2. 监控辅助副本的CPU使用率特别是HADR_DB_COMMAND等AlwaysOn相关线程。3. 在辅助副本上查询sys.dm_exec_requests查找commandLIKE ‘%HADR%’的会话观察其状态。优化辅助副本上的只读查询或使用快照隔离级别减少阻塞。临时应急如果重做队列巨大导致磁盘空间告急可以暂时将出问题的辅助副本从可用性组中移除右键副本-“从可用性组中删除”等主副本日志截断释放空间后再通过“添加副本”向导重新加入并同步数据。但这会暂时失去该副本的保护。5.3 应用程序连接中断或报错现象故障转移后应用程序出现大量连接超时或“找不到服务器”错误。解决要点连接字符串优化// 标准连接字符串示例 ServerAGListener,1433;DatabaseAGDemoDB;Integrated SecurityTrue;MultiSubnetFailoverTrue;Connect Timeout30;ApplicationIntentReadOnly;MultiSubnetFailoverTrue必须添加尤其在多子网环境。Connect Timeout设置合理的值如30秒给故障转移后的重连留出时间。ApplicationIntentReadOnly如果连接只读查询明确指定以实现路由。实现重试逻辑在应用程序代码或数据访问层如使用Polly等重试库中对因故障转移导致的短暂连接错误如错误号4060、64、18456等实现指数退避重试策略。这是构建云原生或高可用应用的基本要求。客户端驱动更新确保使用最新版本的ODBC、OLEDB、ADO.NET或JDBC驱动。旧版本驱动可能对MultiSubnetFailover支持不佳。5.4 磁盘空间不足导致同步挂起这是最危险的场景之一。如果主副本的日志磁盘空间满整个数据库将变为只读事务无法提交。如果辅助副本的磁盘满同步会挂起。预防与处理监控预警建立对主副本和所有辅助副本的数据库文件磁盘空间的监控设置阈值告警如使用Zabbix, Prometheus等。日志增长管理为事务日志文件设置合理的初始大小和自动增长幅度如每次增长1GB避免频繁的微小增长操作影响性能。但更重要的是定期进行日志备份。在AG中日志备份不会打断日志链但能截断日志释放空间。紧急处理如果辅助副本磁盘满导致同步挂起可以尝试清理该副本磁盘上的其他文件。如果主副本日志磁盘满立即进行日志备份是最快的方法。如果备份也无法进行因为事务无法提交情况就非常棘手可能需要扩展磁盘或移动文件这需要计划内停机。搭建和维护SQL Server AlwaysOn可用性组是一个将理论、实践和耐心相结合的过程。它不仅仅是一项技术更是一种保障业务连续性的架构哲学。从最初的严谨规划到搭建时对每个细节的锱铢必较再到运维中对各种监控指标的敏锐洞察每一步都考验着DBA的综合能力。我最深的一点体会是高可用架构的稳定性往往不取决于它成功运行了多久而取决于你对它可能失败的方式了解有多深以及为此做了多少准备。把每次故障转移演练、每次性能压力测试都当成真实的危机来处理不断优化你的检查清单和应急预案这样当真正的故障来临时你才能从容不迫心中有数。