干了十几年数据库运维我说句实话很多公司嘴上喊着“高可用”实际连一次无感知的故障转移都没演练过。SQL Server 跑在单机上碰上硬件告警、操作系统打补丁、机房断电业务就只能跟着一起断。Always On 可用性组这套东西本质就是用一组副本把数据库的“单点风险”分摊掉主库挂了辅助副本自动顶上客户端连接串不用改业务几乎无感。这篇文章我就用手上的 Windows Server SQL Server 环境把从集群搭建到可用性组落地的完整过程拆成五步每一步包含选型思路、操作细节、参数说明和易踩的坑适合刚接触高可用架构的 DBA、运维工程师以及需要自己搭测试环境做验证的开发同学参考。我尽量少讲虚的多给能直接照做的命令和配置。1. 动手之前Always On高可用架构的核心思路1.1 Server级高可用不等于“加一台机器”很多人一提到高可用第一反应就是“多买两台服务器装两个数据库同步一下数据”。这个思路方向没错但把问题想简单了。Always On 可用性组Availability Group简称 AG和传统的日志传送、数据库镜像有本质区别AG 把一组数据库当成一个整体来管理每个副本都是一份完整的数据库主副本处理读写辅助副本既能做灾备也能通过只读路由分担查询压力还支持自动故障转移。而且故障转移的粒度可以精确到“某个可用性组”不是整个实例一起倒这对多业务共库的场景非常友好。关键点在于Always On 并不是 SQL Server 自己的东西它是构建在 Windows Server 故障转移集群WSFC之上的。也就是说SQL Server 里的 AG 只是“上层应用”下面必须有一个健康的 WSFC 集群在支撑SQL Server 才能感知节点状态、仲裁结果、网络心跳这些信息。所以搭建路线是固定的先有域环境再建 WSFC然后装 SQL Server最后配 AG。这四层顺序不能乱网上很多“搭建完 AG 才发现集群仲裁有问题”的翻车案例基本都是前置没做好。1.2 环境与版本怎么选选型是所有工作的第一步这里我直接给推荐配置照抄就行组件生产推荐测试环境最低要求说明Windows Server2019/2022 标准版或数据中心版2016 及以上旧版本如 2012 R2 也能用但不建议新项目再上SQL Server2019/2022 企业版2017 及以上企业版标准版从 2016 SP1 开始支持“基本可用性组”但功能受限域控独立两台ADDNS一台即可WSFC 强依赖 AD 做计算机对象DNS 负责解析器副本数量2~3 个2 个2 副本见证3 副本最佳存储本地盘文件共享见证本地盘不强制共享存储这是 AG 相比传统集群的一大优势这里插一句版本建议生产环境能用 SQL Server 2019 或 2022 就别用 2016因为老版本不支持自动种子Automatic Seeding建副本时要手动做备份还原步骤多自动化程度低。Windows Server 选 2019 以上因为新版本对 WSFC 的节点健康检测更可靠。如果公司有正版授权流程务必走合法渠道测试环境用评估版其实也够用了重点是把架构原理跑通。1.3 五步路线图先看全局再动手整个搭建过程我把它压成五步每一步都有一个明确的“完成标志”方便自检第 1 步配置域控、加域、准备见证资源搭建 WSFC 故障转移集群。完成标志两个节点在故障转移集群管理器中状态为“联机”。第 2 步在两台节点上安装 SQL Server勾选 Always On 可用性组功能启用 HADR 服务。完成标志SQL Server 配置管理器里 Always On 状态为“已启用”。第 3 步通过可用性组向导创建 AG把业务数据库加入可用性组配置数据同步。完成标志主副本和辅助副本的数据库都显示“已同步”。第 4 步创建可用性组侦听器配置静态 IP 和路由规则。完成标志应用可以不再连实例名改为通过侦听器连接。第 5 步做计划内手动故障转移演练验证数据不丢、连接不断。完成标志主副本切换成功后应用连接自动漂移业务无感知。五步走下来一套完整的高可用链路就通了。下面的章节我会逐条展开每一步的实操细节。2. 第1步Windows Server故障转移集群搭建2.1 网络、磁盘和域环境准备WSFC 对网络环境的要求并不复杂但有个容易忽略的点心跳网络和业务网络要分开。我见过很多小团队图省事两台机器就一条网线结果集群在重负载时出现裂脑误判。正确做法是每台节点至少两块网卡一块走业务和客户端通信一块走集群心跳节点间通信两块网卡配不同网段心跳网卡不要配置网关DNS 也不要指向自己。磁盘方面AG 和传统集群的差异在于不要求共享存储每台节点当然是本地盘也不用配 iSCSI 或光纤存储这大大降低了搭建门槛。但是仲裁资源必须考虑好两节点集群建议配一个文件共享见证三节点及以上可以用多数节点模式。文件共享见证随便找一台服务器共享一个目录就行我一般放到域控上NTFS 权限给两台 SQL 节点机器的计算机账户“完全控制”。域环境的资源清单如下两台 Windows Server 虚拟机或物理机各自配置固定 IP计算机名建议用有意义的标识比如 SQLNODE01、SQLNODE02。一台域控服务器生产环境建议两台测试一台也可以装好 AD 域服务和 DNS 服务。一个文件共享目录例如 \DC\WSFC-Quorum供仲裁使用。2.2 加域与集群前置检查先把两台 SQL 节点加到域里。注意加域前必须保证 DNS 配置正确节点的首选 DNS 指向域控 IP否则加域会报“找不到域控制器”。加域完成后用域账户登录每台节点把 SQL Server 服务账户规划好。我的习惯是创建两个域账户一个专门跑 SQL Server 服务如 sqlsvc另一个跑 SQL Server Agent如 sqlagent权限控制在“允许本地登录作为服务登录”别图省事都用本地 SYSTEM因为后续 AG 副本互相通信时会涉及跨节点的权限认证域账户处理起来清爽得多。加域完成后可以提前安装集群功能。打开 PowerShell 分别在两台节点执行Install-WindowsFeature Failover-Clustering -IncludeManagementTools装完功能后建议运行集群验证向导做一次完整验证。在故障转移集群管理器中点击“验证配置”添加两台节点后全选测试项。重点看以下输出节点网络配置是否一致、仲裁配置建议是什么、存储是否正常。验证结果最好没有红色错误黄色警告可以接受但要看清楚警告内容比如时间同步警告通常在虚拟化环境常见影响不大。2.3 创建集群与仲裁见证配置验证通过后就可以正式创建集群了。右键“故障转移集群管理器”里的“故障转移集群”选择“创建集群”填入节点名称指定集群名称和 IP 地址。比如集群名叫 SQLCLUIP 用 192.168.10.20。创建过程会往 AD 里写一个集群计算机对象涉及的域账户要确认有创建计算机对象的权限否则会报权限不足。集群创建完成后我为这个两节点集群配置仲裁模式为“节点和文件共享多数”。操作路径是右键集群 → 更多操作 → 配置集群仲裁设置 → 选择仲裁见证 → 配置文件共享见证。填上 \DC\WSFC-Quorum 共享路径即可。这里解释一下为什么不用磁盘见证AG 场景下磁盘见证需要额外准备共享磁盘有点麻烦而文件共享见证不需要具备仲裁盘的能力只要网络可达、始终在线就行。两节点 文件共享见证等于三票任何单节点宕机剩余节点见证还是两票集群不会裂脑这是两节点高可用的标准配置。完成标志自查集群节点状态显示“联机”仲裁配置为“节点和文件共享多数节点和文件共享见证”。到这里WSFC 容器就绪了后面 Always On 才能顺利“装进来”。3. 第2步SQL Server安装与Always On启用3.1 安装数据库引擎时的关键勾选在 SQLNODE01 和 SQLNODE02 上安装 SQL Server版本和补丁尽量保持一致。安装过程有几个细节需要注意在“功能选择”界面除了数据库引擎服务勾选“Always On 可用性组”功能这个功能在“实例功能”那个区域里默认不勾选很多人漏掉这一步导致后面安装完成后界面里根本看不到 Always On 相关选项。实例名建议保持默认实例MSSQLSERVER因为侦听器、连接串、运维脚本都按默认实例写最省事。如果公司有多个业务需要隔离用命名实例也可以但你需要在后续配置中额外处理端口和实例名的解析复杂度会明显上升生产环境非必要不这样做。服务账户设置我用域账户 sqlsvc 和 sqlagent 分别作为数据库引擎、Agent 服务的启动账户设置密码并配置密码永不过期策略。排序规则、身份验证模式按项目要求来但有一件事必须统一两台上装的时候SQL Server 排序规则必须一致否则后面辅助副本加入可用性组时会报排序规则不匹配。3.2 启用Always On可用性组功能装完两台实例后打开 SQL Server 配置管理器在“SQL Server 服务”节点下右键 SQL Server 服务实例选择“属性”切到“Always On 高可用性”选项卡。你会看到可用的故障转移集群名称就是刚才创建的 WSFC勾选“启用 Always On 可用性组”点击确定后服务会重启。这一步在 SQL Server 侧创建了一个 Windows 故障转移群集名称的依赖背后做的事情是注册了 Always On 相关的虚拟机 DLL、挂了集群资源。如果这一步报错“无法启用 Always On”九成原因是当前节点没有正常加入 WSFC或者 SQL Server 服务账户对集群的权限不足。检查方法是在“故障转移集群管理器”里确认节点状态再在 PowerShell 里用Get-ClusterNode看节点状态。启用完成后再打开 SQL Server Management StudioSSMS在实例对象资源管理器里就能看到“Always On 高可用性”文件夹此时里面是空的因为还没创建可用性组。保险起见两台节点都做一遍这个启用操作。3.3 数据库前置条件与备份策略调整AG 里的每个数据库必须满足三个硬性条件处于完整恢复模式、至少做过一次完整备份、不在系统数据库中master 等。在创建可用性组前先把目标数据库切到完整恢复模式ALTER DATABASE [YourDB] SET RECOVERY FULL; GO BACKUP DATABASE [YourDB] TO DISK ND:\Backup\YourDB.bak WITH INIT, COMPRESSION; GO为什么要强调“完整恢复模式”因为 AG 的数据同步靠事务日志简单恢复模式不保留日志记录根本无法同步大容量日志恢复模式虽然能做但中间的日志链更容易断生产环境还是老老实实完整恢复。备份则是为了初始化辅助副本。另外要想清楚备份策略怎么调。启用 AG 后主副本上每天凌晨的全备、日志备份原则上都可以继续做但更好的做法是启用“备份首选副本”把备份负载转移给辅助副本。这个设置可以在后面创建可用性组时顺便配置也可以在创建后通过 AG 属性里的“备份首选项”修改。我用的是“首选辅助副本”这样主库的 IO 压力能小一点而且在辅助副本上做备份不会影响主库的日志传送链。4. 第3~5步可用性组创建、侦听器配置与故障转移验证4.1 第3步创建可用性组用 SSMS 连到主副本实例右键“Always On 高可用性” → “新建可用性组向导”。向导里有几个界面值得展开讲。“选择数据库”页面会列出该实例上满足条件的数据库不满足条件的会显示原因比如“此数据库不在完整恢复模式中”或“此数据库尚无备份”。如果列表里看不到目标库先回头检查恢复模式和备份别硬往下走。“指定副本”页面里先点击“添加副本”把辅助实例 SQLNODE02 加进来。默认连接时向导会要求你提供辅助实例的系统管理员权限用域账户 sqlsvc 就行。然后是三个核心设置可用性模式生产环境强烈建议“同步提交”。同步提交虽然对网络延迟更敏感但能保证主副本和辅助副本的数据一致故障转移时不丢数据异步提交适合跨机房容灾、对延迟要求高的场景但故障转移可能丢最后一段日志。自动故障转移两个副本都放同步提交模式勾选自动故障转移AG 才能实现无人值守切换。注意自动故障转移本质上是 WSFC 的健康检测在起作用需要主副本、辅助副本都满足条件。读取路由这里暂时不配可后面单独设置。“选择数据同步”页面选“自动种子设定”前提是 SQL Server 版本是 2016 或更高且辅助实例能通过网络访问主实例的日志流端口。如果版本低于 2016只能选“完整备份和日志备份”向导会要求先手动做一次备份还原到辅助库再通过日志备份把数据库带入同步状态。最后“验证”页面会执行一系列检查常见错误包括节点时钟偏差超过阈值、订阅副本实例排序规则不一致、服务账户权限配置不当。逐个处理完点击完成向导会在主实例上创建 AG并向辅助实例发送加入请求。创建完成后在“Always On 高可用性”文件夹下能看到可用性组名字展开可看到两个副本和数据库的同步状态。如果辅助副本的数据库状态一直是“正在同步...”说明同步没正常跑起来需要去系统健康日志或sys.dm_hadr_database_replica_states里看同步细节。4.2 第4步创建侦听器侦听器是业务访问数据库的“门面”。没有侦听器应用就得指定具体的实例名主库切换后还要改连接串高可用就失去了意义。有了侦听器应用只需要记住一个固定的虚拟网络名称和端口故障转移后 TCP 连接自动漂移。在 SSMS 里右键可用性组 → “添加侦听器”输入名称例如 AGListener端口填 1433网络模式选“静态 IP”填一个业务网段内未被占用的 IP例如 192.168.10.50。确认后向导会在 WSFC 中创建集群网络名称资源并把它附加到可用性组上。客户端连接串有讲究必须加一项MultiSubnetFailoverTrue尤其是副本分布在不同子网时。举例ServerAGListener,1433;DatabaseYourDB;User Idsa;Password****;MultiSubnetFailoverTrue;MultiSubnetFailover这个参数的作用是让客户端并行尝试所有子网一旦主副本切换TDS 能够快速响应新的 IP而不是傻等着 TCP 超时。很多应用连接 AG 失败或切换后重连半天就是因为连接串里漏了这个参数。4.3 第5步故障转移演练验证业务连续性创建 AG 只是第一步真正的验证是故障转移演练。千万别等生产故障了才第一次触发故障转移那是在给自己埋雷。计划内手动故障转移是数据零丢失的切换方式。操作路径SSMS 连到辅助副本实例 → “Always On 高可用性” → 右键可用性组 → “故障转移”。向导会先检查主副本状态确认辅助副本已同步点击完成就开始角色互换。整个过程一般在几十秒内完成业务连接会短暂中断但无需改任何连接串。演练时重点观察三件事WSFC 中角色是否成功从主副本转移到辅助副本。新主副本上的数据库是否仍处于“已同步”状态。应用程序使用侦听器连接是否正常回连。演练完成后我习惯再手动切换回原主副本恢复初始拓扑。并且把演练时间、切换过程、异常点记录到运维文档里方便以后复盘。如果你想把测试做得更接近真实故障可以模拟“硬故障”直接对主节点执行Stop-Service ClusSvc或者直接强制关机观察自动故障转移是否触发。注意这种暴力测试一定不要在业务高峰期做事前要和开发、业务方打好招呼。5. 常见问题速查与上线前避坑清单5.1 高频问题症状对照表这里把我实际踩过、带人踩过的坑整理成一张速查表遇到问题时直接按症状对着查。症状可能原因处理建议创建 AG 时提示“无法联接到可用性组副本”辅助实例未启用 Always On或防火墙阻止镜像端点端口先启用 Always OnGet-ClusterNode确认节点联机放行 5022 等镜像端口辅助副本数据库一直“正在同步…”日志链中断、网络质量差、自动种子失败检查sys.dm_hadr_database_replica_states和错误日志必要时从备份重新初始化无法启用 Always On 可用性组功能SQL Server 服务账户缺少集群权限或未正确加入 WSFC把服务账户加入本地管理员确认 WSFC 状态为“联机”自动故障转移不触发可用性模式不是同步提交、未勾选自动故障转移、WSFC 仲裁配置异常检查副本属性确保两副本角色健康和自动故障转移条件均满足故障转移后应用连接超时或失败连接串缺少 MultiSubnetFailoverTrue在所有连接串中加上该参数并重新测试客户端连接报“无法访问数据库”数据库在辅助副本上处于辅助角色未启用只读路由配置只读路由或在连接串指定 ApplicationIntentReadOnly5.2 我踩过的坑与排查思路关于数据库镜像端点的端口默认是 5022但它不是一个固定端口创建 AG 时会自动在每台实例上生成一个“数据库镜像端点”。如果两台节点之间有防火墙必须放行这个 TCP 端口。排查方法很直接在两台节点上分别执行以下命令查端口SELECT name, type_desc, port FROM sys.tcp_endpoints WHERE type 4;除此之外副本加入失败时SSMS 向导给的错误信息往往不够精确。我的习惯是直接看 Windows 事件日志里的“应用程序”日志和 SQL Server 错误日志特别是sp_server_diagnostics的运行记录。Always On 健康检测每 30 秒跑一次如果检测失败事件日志会清楚地记录健康检测状态。还有一个很多人忽略的点SQL Server 服务账户和 SQL Agent 账户不要是同一个域账户且避免账户密码过期。我在一个客户现场遇到过数据库正常运行但故障转移时集群无法用服务账户登录辅助节点最后切换失败的案例。原因就是服务账户密码到期后没有及时更新SQL Server 服务已经无法访问集群资源。排查这种问题重点看集群日志和 SQL Server 错误日志中关于服务账户登录失败的记录。5.3 上线后的监控与备份策略建议AG 搭好不是终点是运维的起点。上线之前一定要把监控补上。至少需要盯四个指标可用性组健康状态Healthy / Not Healthy。数据同步延迟查询sys.dm_hadr_database_replica_states里的last_commit_time差值。WSFC 仲裁和节点状态仲裁异常意味着集群根本没法正常工作。Windows 事件日志中与 FailoverClustering、AlwaysOn 相关的事件。SSMS 自带的“Always On 仪表板”是个快速入口能看到备次级、同步状态、故障转移状态。更进一步的监控可以考虑用扩展事件alwayson_health把健康检测的详细信息采集出来配合告警平台使用。备份策略我也建议做一次调整全量备份放到辅助副本上执行日志备份在主库上继续主库上的完整备份可以只保留一份作为保险。开启“备份首选项”后备份作业要允许辅助副本执行需要用支持“副本备份”权限的账户。如果辅助副本因为某种原因不可用备份作业要能够自动回退到主库执行这需要在作业代码里做状态判断。最后提一句读取扩展如果业务有明显的只读查询可以在 AG 里把只读路由配置起来连接串中指定ApplicationIntentReadOnly的请求会被路由到辅助副本这样既能提高资源利用率也减轻主库压力。但要注意读副本的延迟在异步提交模式下可能很大同步提交模式相对靠谱一点具体用哪种模式要结合业务的容忍度。我在实际部署 Always On 的过程中最大的体会是这个架构本身并不难难的是把所有前置条件做到位。域环境、集群仲裁、服务账户、防火墙、端口、数据库恢复模式任何一个环节掉了链子故障转移时就会给你颜色看。所以耐心跑一遍五步流程认真做一次故障转移演练比看十篇文档都有用。如果你的环境里数据库不止一套也可以考虑一个可用性组管理多个数据库只要它们之间的依赖关系一致操作思路是完全相通的。