一开始我想部署AlwaysOn的时候心里其实挺没底的。看了不少文档信息很全但也正因为太全反而不知道该从哪儿下手。那会儿手头刚接手一个核心业务库老板要求实现高可用丢数据不能超过可接受范围故障切换时间尽量短。我把备份还原、日志传送、数据库镜像都对比了一圈最后才确定AlwaysOn可用性组这条路。这方案既能做高可用又能让辅助副本承担只读查询算是SQL Server环境里性价比很高的选择了。这篇文章不打算复述官方文档而是把我从零开始部署的基础过程、踩过的坑、以及部署完之后的思考都写出来。目标是让一个没有接触过AlwaysOn的人看完之后能大概知道要准备什么、先干什么后干什么、遇到问题往哪个方向排查。1. 先想清楚再动手AlwaysOn到底解决什么问题1.1 高可用方案不是越多越好关键是搞懂差异Anyone做过数据库高可用选型的应该都有体会SQL Server能用的方案实在太多了。最简单粗暴的就是备份还原但恢复时间取决于备份大小少则几十分钟多则几小时。日志传送能做到较快的恢复但日志备份有延迟意味着可能丢数据而且切换需要手动干预操作繁琐。再就是数据库镜像它能做到秒级切换但只有一个辅助副本而且镜像会话维护起来比较麻烦。AlwaysOn可用性组和这些方案最本质的区别在于它是在数据库副本级别做保护而不是实例级别。多个辅助副本都可以持有数据库的实时副本支持同步和异步两种提交模式还允许辅助副本以只读方式访问直接用来跑报表和查询减轻主库压力。这里要特别强调AlwaysOn可用性组依赖于Windows故障转移集群WSFC它提供的是集群中的高可用能力资源副本切换只是其中的一项功能。你在两台甚至多台服务器上都装了SQL Server实例这些实例都加入了同一个WSFC集群然后我们可以随时把主库从一个节点挪到另一个节点上。1.2 哪种业务场景适合上AlwaysOn老实说上AlwaysOn之前应该先做评估不是所有业务都适合。如果你现在的核心痛点是半夜数据库服务器物理挂了业务长时间不可用恢复手段只有找备份慢慢恢复那AlwaysOn值得上。它提供自动故障转移能力能在主节点不可用后自动将辅助副本提升为主副本整个过程通常是几十秒级别当然业务应用连接串要做配套调整。如果你的业务高峰期查询压力很大又在想怎么把一部分查询给卸掉那AlwaysOn的只读副本就是现成的读写分离方案。辅助副本也能跑查询前提是你设置了只读路由和应用程序启用只读意图。反过来有些场景我并不建议上AlwaysOn。比如你的项目只有一台小服务器、预算有限、IT团队对Windows集群不熟那我建议先把备份体系做扎实不要盲目搞高可用。AlwaysOn同步提交模式下每个事务都要等辅助副本确认落盘跨机房网络延迟高了主库性能是一定会受影响的。小项目没专职DBA维护的话高可用反而可能把你的复杂度推高到一个应付不来的水平。我见过不少团队部署完AlwaysOn之后就觉得万事大吉了实际上副本之间同步是否正常、集群仲裁状态是否健康、日志磁盘是否会撑爆这些都是日常要持续关注的。高可用系统的核心价值其实是从挂了慢慢恢复变成挂了马上切换而不是说挂了就没有损失了切换本身也有时间成本业务断连半分钟的容忍度得提前和业务方确认清楚。2. 部署前的环境准备与技术决策2.1 软硬件清单和版本要求做部署规划的时候我习惯先列一份清单把软硬件和版本要求明确下来。AlwaysOn最少需要两个节点一个主副本一个辅助副本。生产环境我更倾向于三节点或两节点加见证不过基础模式两步其实够用。操作系统方面我用的是Windows Server 2019SQL Server 2016以上都支持AlwaysOn但还是建议选合适的版本。所有节点的操作系统版本尽量一致反正补丁也建议打到相同级别不然之后排查起来容易出很多稀奇古怪的问题。SQL Server版本这里一定要特别留意所有节点必须是同一个主版本比如都是SQL Server 2016不能一个2016一个2019这是硬性要求安装了不匹配的版本之后加入副本的时候就会报错。Active Directory域环境是必须的。所有节点包括SQL Server服务器都要加入同一个域域控建议单独一台不要和数据裤节点搅在一起。如果公司没有现成的域环境需要先搭建AD域服务和DNS这个在Windows Server上通过添加角色就能做后面我会具体说。服务账号规划上我强烈建议为SQL Server服务单独创建一个域账号两个节点都用同一个账号运行SQL Server服务。之前见过有人用Network Service甚至本地账号跑创建可用性组的时候差点没把人逼疯哪怕集群层面没问题SQL Server资源也起不来。有条件用组托管服务账号gMSA是最好的不用定期改密码日常维护省心很多。2.2 网络规划和端口清单网络规划这一块很多人会忽视。生产环境至少配两块网卡一块走业务流量一块走集群内部通信。心跳网络建议用独立的IP子网段速度和稳定性优先因为集群依赖它做节点状态判断。端口方面列一个我实测过的清单照着这个做防火墙规整就行用途端口/协议备注SQL Server数据库引擎TCP 1433客户端连接AlwaysOn可用性组端点TCP 5022副本间数据同步专用默认Windows故障转移集群通信TCP 3343集群节点间通信集群动态RPCTCP 49152-65535部分场景会用到NetBIOS备用UDP 137/138老环境下可能需要SMB文件共享TCP 445文件共享见证和备份可能用到这几项是基础每个节点的Windows防火墙都要把这些入站规则加上如果机房还有独立防火墙那也要考虑到别只调了Windows防火墙结果被物理防火墙挡住。排障的时候遇到过太多次这种低级问题两个节点明明内网互通可用性组端点就是连不上一查防火墙端口没放行白白排查了一个下午。2.3 同步提交还是异步提交这是个取舍问题AlwaysOn的模式里最容易搞混的就是同步提交和异步提交。同步提交模式下主库的事务日志需要在辅助副本上落盘确认主库事务才算提交成功。这种模式的好处是RPO为零不丢数据代价是性能有损耗尤其是跨机房高延迟网络下非常明显。它也是自动故障转移的前提如果你配置的是异步提交那自动故障转移按钮是灰色的想切换只能手动强制切换强制切换是有可能丢数据的。异步提交则是主库不用等辅助副本确认性能几乎没有额外开销但万一主库宕机辅助副本可能没有最新的数据丢多少取决于当时日志同步的落后情况。适合异地容灾节点因为异地网络延迟高强制同步提交会把主库拖死。我生产环境的习惯是同机房两个节点用同步提交加自动故障转移异地灾备节点用异步提交加手动强制故障转移。这样既保证了核心场景不丢数据又不会把异地这个副本变成主库性能瓶颈。另外提醒一个容易踩的坑虽然文档里把自动故障转移写成可用性组支持两个自动故障转移副本但实际配置多个同步副本时最好只让其中一个辅助副本参与自动故障转移伙伴关系这样才能避免多个副本同时提升带来的脑裂风险。WSFC在故障转移时有自己的仲裁机制来保证唯一所有者但应用连接层如果配置了多个目标反而容易出意外。3. 基础架构搭建从Windows集群到SQL Server实例3.1 域环境和DNS的准备过程如果你的IDC里已经有AD域服务器了这一步直接跳过配置SQL节点加域即可。如果要从零开始搭假设在Windows Server上安装AD域服务和DNS服务步骤很简单添加AD域服务角色然后执行域控制器的提升向导指定一个目录林根级域名。期间会要求一并安装DNS服务这个建议装上因为AlwaysOn的可用性组监听器要依靠DNS解析虚拟网络名称。域搭好之后把所有的SQL Server节点都执行加域操作。加域过程中需要域账号权限加完域后记得重启服务器。这里有一个小建议加域之前把每台服务器的计算机名规划好因为一旦加入域再改名称虽然技术上也可以但集群和DNS都可能会有一连串的困扰不如一开始就定好命名规则比如SOL-SQL01、SQL-SQL02这种方便后续运维识别。DNS这一块也不要大意集群和可用性组都依赖DNS解析。我遇到过一次监听器IPping得通但客户端就是连不上的情况排查到最后发现是DNS反向解析记录没注册虽然正向解析正常但客户端做反向验证的时候失败。所以DNS服务器上一定要确认集群名称对象和可用性组监听器的正向、反向记录都存在并正确。3.2 创建Windows故障转移集群集群的创建一般用故障转移集群管理器或者PowerShell来做。我自己的习惯是用PowerShell脚本方便反复执行和事后回溯。步骤如下在每台服务器上安装故障转移集群功能。Windows Server操作中心里有添加功能和功能向导或者直接命令行安装。Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools运行集群验证测试。这一步很关键它会检查存储、网络、系统配置等是否满足集群要求。验证产生的警告要仔细看比如网络适配器命名不一致、多网卡未正确配置这些能处理的提前处理掉。Test-Cluster -Node SQL01,SQL02 -Include Inventory,Network,System,Storage创建集群。指定集群名称和节点如果要自定义IP地址的话也要在参数里指定。New-Cluster -Name SQLCLU01 -Node SQL01,SQL02 -StaticAddress 192.168.10.20创建完成之后打开故障转移集群管理器应该能看得见集群状态正常、两个节点都已加入。这里要说明集群本身不一定需要共享存储AlwaysOn可用性组用的是数据库副本机制数据文件存在各节点本地磁盘上这一点和SQL Server故障转移集群实例FCI完全不同刚接触的时候不要搞混——FCI才需要共享存储AG不需要。3.3 仲裁配置决定集群存活的关键仲裁是很多人觉得复杂、容易忽视的部分但它恰恰决定了集群在故障时的生死。如果仲裁失败集群资源会离线整个AlwaysOn都无法对外提供服务了。仲裁配置的核心思路是让集群在出现节点分区时依然能判断哪边够资格继续运行。常用的仲裁配置有节点多数、节点和磁盘见证、节点和文件共享见证Windows Server 2016之后还支持云见证可以直接用Azure的存储账户不过内网环境一般用不上。我在实际项目中习惯配置节点多数 文件共享见证。因为不引入额外磁盘实现成本低容错能力比单纯节点多数好一些。文件共享见证需要一台额外的机器提供一个共享目录这台机器最好不是集群成员比如域控或者监控服务器就挺合适。有一点要注意仲裁磁盘见证所用的磁盘本身不能是集群存储资源否则会造成循环依赖。我自己就曾经因为图省事把见证放在其中一个节点上结果该节点宕机后集群无法正常仲裁虽然是测试环境教训还是很深刻。3.4 在两台节点上安装SQL ServerSQL Server安装过程本身比较常规但有几个细节要特别注意两台节点的SQL Server版本、补丁级别必须一致这是铁律。版本不一致会导致副本之间无法同步或者故障转移之后服务状态异常。SQL Server服务账号指定为同一个域账号这个账号要预先在AD中创建并赋予其适当的权限。安装时选择SQL Server功能安装包含数据库引擎服务。AlwaysOn可用性组本身不依赖SSIS、SSRS这些组件基础功能就够了。数据文件、日志文件的路径在两台节点上建议保持一致比如都放在D:\Data和D:\Logs,虽然AG不强制要求路径一致但路径一致会让后续的自动种子和手动维护简单不少。安装完成后先别急着配置AG先把两个SQL Server实例都启动并且确认能够正常登录。然后用SQL Server配置管理器把AlwaysOn可用性组功能启用上路径是SQL Server服务里右键对应的实例选择属性在AlwaysOn高可用性选项卡里勾选启用AlwaysOn可用性组。启用后需要重启SQL Server服务这一步很容易忘记导致后面创建可用性组时发现硬件或功能不满足提示。4. 核心操作创建可用性组配置监听器与副本4.1 数据库备份与还原初始同步的前置条件创建可用性组之前数据库自身的准备工作是绕不开的一步。AG要求数据库必须使用完整恢复模式如果是简单恢复模式会直接创建失败。还有一点数据库里如果有文件是只读的AG创建时也会报错需要把相关文件改成可写状态。在做初始数据同步时我通常选择完整备份和还原方式步骤是先在主节点上对数据库做一次完整备份然后手动把备份文件拷贝到辅助节点在辅助节点上用NORECOVERY还原。这样做的好处是对初始数据量较大的库来说整个流程都在可控范围内恢复速度取决于磁盘IO和网络传输。如果数据库不大也可以用自动种子方式在建AG的时候直接勾选自动种子选项辅助副本会自动从主副本拉取数据。这个功能确实方便但我建议首次部署还是先手动备份还原一遍至少能理解数据同步的原理出了问题也好排查。操作示例主节点备份BACKUP DATABASE [YourDB] TO DISK ND:\Backup\YourDB.bak WITH INIT辅助节点还原RESTORE DATABASE [YourDB] FROM DISK ND:\Backup\YourDB.bak WITH NORECOVERY注意这里的NORECOVERY一定不能省否则辅助副本无法加入可用性组这是最经典的报错原因之一。4.2 创建可用性组的完整流程有了集群有了启用了AlwaysOn的SQL Server实例有了已备份还原的数据库接下来就用SSMS的向导来创建可用性组。在SSMS里展开Always On高可用性节点右键可用性组选择新建可用性组向导。向导中有几个关键点指定可用性组名称比如AG-YourDB。名称在DNS里会作为监听器的别名建议起得有业务含义方便后续辨识。选择数据库。列表里会展示当前实例上符合AG要求完整恢复模式、非只读的数据库。指定副本。把第二个节点添加进辅助副本列表设置可用性模式为同步提交故障转移模式为自动并勾选可读次要副本如果需要用辅助副本扛查询。选择数据同步方式。刚才我建议先手工备份还原的在这里就选仅加入或跳过初始数据同步因为数据已经准备好了。配置监听器。填写监听器DNS名称和端口比如LISTENER-SQL端口用默认1433。注意这里指定的是虚拟IP必须和两个节点不在同一个IP上冲突建议用静态IP并提前在DNS或网络组申请好。最后点击创建。整个过程执行完成后SSMS里应该能看到新建的可用性组两个副本状态显示在线数据库同步显示已同步。4.3 配置端点与权限细节创建过程中SQL Server会自动为每一个副本创建数据库镜像端点默认端口5022。你可以在SSMS里查看到端点信息SELECT name, protocol_desc, port, state_desc FROM sys.tcp_endpoints WHERE type_desc DATABASE_MIRRORING端点的权限有时候会因为实例重启或账号调整而丢失导致副本间连接失败。遇到过几次主要表现就是辅助副本一直显示未同步或断开连接解决方法是手动授予CONNECT权限。当然生产环境有更规范的账号管理方式这里先按最直接的方式来处理GRANT CONNECT ON ENDPOINT::Hadr_endpoint TO [DOMAIN\sqlservice]建议把这类语句记到自己的操作手册里因为故障转移之后主副本节点会变需要在新的主节点上再检查一遍权限状态。4.4 监听器与客户端连接监听器配置是最能直接感受AlwaysOn价值的一步。配置好之后客户端只需要连接监听器的域名或IP比如sql-clu01.domain.com1433端口无论主副本在哪台节点连接都会自动转发到当前主副本所在的SQL Server实例。对应用来说就一个连接字串不用跟随主备切换改连接配置这才是真正面向业务的高可用体验。连接字符串里如果是多子网环境要加上MultiSubnetFailoverTrue。这个参数的作用是让客户端同时尝试多个IP地址加快故障转移后的重连速度。这个参数在.NET的SqlClient里是支持的老版本或者旧驱动不一定认部署前最好让开发和DBA两边都确认一下驱动版本避免因为驱动太老导致始终连不上监听器。如果想让辅助副本分担读取压力还需要配置只读路由。三个环节缺一不可辅助副本在副本属性里勾选可读次要副本给可用性组配置读取时路由列表客户端在连接字符串里加上ApplicationIntentReadOnly。只有这三个都满足ReadOnly连接才会自动转发到辅助副本否则就直接连到主库了。刚开始配的时候踩过这个坑以为勾了个可读就完事了结果报表连的还是主库白折腾半天。5. 部署完成后的验证与常见坑5.1 故障转移验证的完整思路创建完可用性组先别急着收工。我习惯做一轮故障转移验证确认这套东西在关键时刻真的能接管业务。验证分两个维度手动故障转移和自动故障转移。手动故障转移的验证方法是在SSMS右键可用性组选择故障转移向导会提示目标副本是哪一个按要求完成切换。切完之后确认数据库状态是已恢复或可读写原主副本变成辅助副本数据仍然一致。自动故障转移的验证更有挑战性。最简单的方式是直接停止主节点上的SQL Server服务模拟主库崩溃观察辅助副本是否自动抢主。建议在业务低峰期操作并提前做好业务方的沟通。手动的PowerShell方式也可以用以下命令触发Restart-Service -Name MSSQLSERVER -Force这个命令执行后如果可用性组配置检查无误辅助副本在几十秒内会变成主副本监听器指向也会跟着切换。建议同时检查一下Windows事件日志里的集群日志确认没有仲裁相关警告。切完之后一定要记得把服务重新启动并确认集群里所有节点都恢复健康状态。5.2 我踩过的坑与排查思路这一节是我最想写的因为很多问题不实际部署一遍根本预想不到光看文档不会遇到。第一个坑防火墙端口未放行副本加入失败。 表现是创建可用性组向导走到一半报错提示无法连接辅助副本。排查时先看端口、再抓包、再看网络组策略最后发现是Windows防火墙入站规则没加5022。后来我把所有节点的防火墙端口清单做成了一张表每次部署都对着表检查再没出过这类问题。第二个坑两个节点SQL Server补丁版本不一致。 某个节点升级了补丁另一个没升结果主副本切换过去之后数据库无法自动加入可用性组只能手动恢复数据库并重新加入。这个坑的隐蔽性在于升级补丁的时候不一定想到要同时升级所有副本节点所以版本一致性这个要求我在部署文档里用醒目的字体标了多次。第三个坑自动故障转移不生效。 有段时间辅助副本一直停在未同步状态事件日志里显示连接超时。最后发现是心跳网络不稳定集群本来就处于降级状态。网络质量对AG的影响被很多人低估尤其是同步提交模式下哪怕2-3秒的网络抖动都可能造成主库事务阻塞。建议部署前用性能监控工具对两个节点之间的网络延迟和丢包做持续测试如果延迟超过5毫秒就要慎重考虑是否使用同步提交。第四个坑监听器连接偶尔超时。 原因是对应的DNS记录更新延迟。故障转移发生时监听器的IP实际上会从一个节点漂移到另一个节点但如果DNS缓存没刷新客户端可能连接失败。在DNS TTL设置上建议把监听器记录TTL调低比如300秒同时客户端侧正常设置重试机制。对要求高的环境可以考虑在应用连接串里增加连接重试参数。5.3 部署完之后还想再多说几句AlwaysOn部署完成只是一个开始日常监控和管理才见真功夫。我的建议是在每个节点上启用AlwaysOn仪表盘视图定期观察副本同步状态、延迟、故障转移历史。针对长时间未同步的数据库第一时间去看可用性组仪表盘查看最新同步时间如果出现持续延迟还要看日志磁盘剩余空间、网络压力等底层指标。还有一个小习惯我部署完每个AlwaysOn环境都会把下面这组T-SQL脚本存下来方便随时检查集群和副本的状态SELECT groups.name AS AGName, replica_server_name, database_name, synchronization_state_desc, synchronization_health_desc FROM sys.dm_hadr_database_replica_states AS dbrs LEFT JOIN sys.availability_groups AS groups ON dbrs.group_id groups.group_id这个视图能一眼看出每个数据库在副本上的同步状态和健康状况非常实用。另外不要在生产环境上省备份。AlwaysOn不是备份的替代品它解决的是高可用问题误删数据、表结构变更、木马攻击这些场景还是需要依赖传统备份来恢复。很多团队以为有了AG就不用每天做备份了这个想法是危险的。我们有AG备份策略依然会严格执行只是可以把备份方式从在唯一主库上跑变为在辅助副本上做备份这样可以减轻主库的负载这也是可用性组带给我们的额外福利之一。从零到一部署AlwaysOn这条路说难也不算难核心还是要把Windows集群、SQL Server实例、域环境、网络规划这些基础打牢然后再去配置可用性组这个上层逻辑。我建议第一次动手的时候先在一个隔离的测试环境里完整走一遍故障转移再迁移生产库。毕竟高可用本身就是给出故障的场景设计的实际操作过一次心里才有底。