简介这份文档面向 SQL Server 数据库管理员与运维工程师聚焦在已有 Always On 可用性组集群中新增一个数据库节点的完整落地流程适合具备一定故障转移群集基础、需要横向扩展只读副本或提升高可用能力的技术人员参考。资源包内共 1 个 docx 文件约 1.92MB以图文步骤文档形式呈现内容涵盖环境角色与 IP 规划、新节点安装 SQL Server、开启故障转移群集功能、修改各节点 hosts 文件、将新节点加入现有 Windows 故障转移群集、启用 Always On 以及把副本加入可用性组等关键环节并配有详细截图作者亲测可行。目前已有 102 人学习。读者可据此对照自身集群环境理清新增副本的先后顺序与配置要点减少因 hosts 解析、群集节点添加或副本加入失败导致的反复排查快速完成读写分离架构的节点扩容。1. 给 AlwaysOn 集群加副本一次把新节点从裸机接进可用组的完整路径生产库跑在 SQL Server 2016 AlwaysOn 上主副本扛写、辅助副本扛读某天报表和只读查询把现有辅助副本压得喘不过气最直接的办法就是再挂一个只读副本进来分担。这事听起来就是加台机器真动手才知道坑全在细节里Windows 故障转移群集要先认这台机器hosts 要全网对齐AlwaysOn 服务账户得先切过来最后才轮到可用性组里点添加副本。我这次加的是test209.test.com10.106.210.209挂进已有的testgroup1可用组定位是只读副本。下面把从裸机到能读的每一步拆开讲环境是 SQL Server 2016 Windows 故障转移群集主副本test51、辅助副本test52新节点test209。适合正在维护 AlwaysOn 集群、需要横向扩只读节点的 DBA 照着复现。2. 加副本前的环境对齐IP、hosts 与群集角色AlwaysOn 的可用性组本质是建在 Windows 故障转移群集之上的所以加数据库副本这件事被拆成了两层先让 Windows 群集认识新机器再让 SQL Server 的可用性组认识新副本。很多人一上来就冲进 SSMS 点添加副本结果列表里根本找不到新节点就是因为底层群集还没接纳它。这一章先把地基铺平。2.1 先把三台机器的角色和网络理清楚动手前先把拓扑写死避免后面 hosts 改漏。这次的环境是这样角色IP主机名可用组读写策略主副本10.106.210.51test51.test.comtestgroup1写辅助副本10.106.210.52test52.test.comtestgroup1读计划添加的副本10.106.210.209test209.test.comtestgroup1读新节点定位是只读副本所以它不需要参与写但必须和主副本保持同步。这里有个容易被忽略的点AlwaysOn 副本之间的通信走的是数据库镜像端点默认 5022 端口不是靠主机名解析就够但主机名解析不通端点握手一样会失败。所以 hosts 必须双向可达。2.2 新节点装 SQL Server 时的实例名与排序规则新节点上装 SQL Server 软件这一步原文写的是略但这里恰恰是翻车高发区。装的时候有两个参数必须和现有节点对齐否则后面加副本会直接报错。第一个是实例名。AlwaysOn 要求同一可用组内所有副本的 SQL Server 实例名一致。现有节点用的是默认实例还是命名实例新节点必须照抄。如果现有是MSSQLSERVER默认实例新节点也装默认实例如果现有是MSSQLSERVER之外的命名实例新节点实例名要完全相同。第二个是排序规则Collation。可用性组要求所有副本的实例级排序规则一致不一致的话加副本时 SSMS 会直接拒绝。装之前先在主副本上查一下-- 在主副本 test51 上执行确认实例级排序规则 SELECT SERVERPROPERTY(Collation) AS InstanceCollation, SERVERPROPERTY(IsClustered) AS IsClustered, SERVERPROPERTY(ProductVersion) AS ProductVersion;InstanceCollation就是新节点安装时要选的排序规则IsClustered确认现有节点确实在群集里ProductVersion用来核对版本号——AlwaysOn 要求所有副本的 SQL Server 主版本一致2016 对 2016不能混 2019。装新节点时在数据库引擎配置那一步排序规则页签选自定义把查出来的值填进去。提示版本号只要主版本一致即可补丁级别可以不同但建议补丁也拉齐避免同步时出现元数据兼容问题。2.3 开启故障转移群集功能并处理 DNS 角色新节点要加入现有群集必须先装上故障转移群集这个 Windows 功能。原文的操作路径是走服务器管理器打开服务器管理器→添加角色和功能→一路下一步到功能页勾选故障转移群集点添加功能。原文里还勾了DNS 服务器这一步要谨慎。DNS 服务器角色只有在你要把这台机器当 DNS 用的时候才需要纯粹加一个 AlwaysOn 副本并不需要它。如果现有环境已经有独立的 DNS 或者用 hosts 解析新节点上装 DNS 角色反而可能引起解析冲突。我的做法是只勾故障转移群集DNS 角色按现有环境的实际需要决定。如果原文环境确实靠这台机器兼做 DNS那勾上没问题但要确认它不会抢现有 DNS 的解析。装完功能后建议重启一次让群集服务相关组件干净加载。2.4 hosts 文件必须全网对齐这是最容易被跳过、又最容易导致节点加不进去的一步。故障转移群集在验证节点时会尝试用主机名互相解析。如果新节点解析不到老节点或者老节点解析不到新节点验证就会卡在网络那一项。操作分两处第一处在现有所有节点test51、test52的C:\Windows\System32\drivers\etc\hosts里追加新节点的记录10.106.210.209 test209.test.com第二处在新节点 test209的 hosts 里把全部节点的记录都补上10.106.210.51 test51.test.com 10.106.210.52 test52.test.com 10.106.210.209 test209.test.com改完不用重启但建议用ping test209.test.com和ping test51.test.com双向验证一下解析是否生效。hosts 是纯文本注意别存成hosts.txtWindows 默认隐藏扩展名很容易踩这个坑。3. 把新节点接进 Windows 故障转移群集hosts 通了之后才轮到群集层面接纳新节点。这一步在群集当前的主节点上操作走的是故障转移群集管理器。整个过程本质是让群集做一次节点验证验证通过才会正式把新机器纳入群集成员。3.1 从群集管理器发起添加节点在群集当前主节点上打开服务器管理器点工具→故障转移群集管理器。如果管理器打开后没自动连上群集右击左侧根节点故障转移群集管理器选连接到群集输入或选择现有群集名。连上后在右侧操作面板里点添加节点进入添加节点向导。第一步是选择要加入的服务器输入新节点的主机名test209.test.com点添加把它挪到已选列表再点下一步。3.2 验证配置这一步别跳过向导接下来会问是否运行验证配置。这里有个实操取舍正式环境建议跑完整验证它会检查网络、存储、系统配置等一整套项目能提前暴露 hosts 没通、防火墙挡了、版本不一致之类的问题。如果只是测试环境想快可以选不运行验证但生产上我一般强制跑一遍。验证里最常挂的两项网络如果新节点和老节点之间某些网段不通或者 hosts 没对齐这里会红。系统配置如果新节点没装故障转移群集功能或者 SQL Server 版本/排序规则不一致这里会提示。验证通过后向导会把新节点正式加入群集完成后在节点列表里能看到test209。3.3 加入后确认群集成员状态加完别急着走回到群集管理器确认一下# 在群集任意节点上以管理员身份运行查看群集节点状态 Get-ClusterNode | Format-Table Name, State, NodeWeight -AutoSizeState应该是UpNodeWeight默认是 1参与投票。如果新节点显示Down或者权重异常先别往下走回头查群集服务和网络。这一步确认干净了SQL Server 层面才有意义。注意如果群集开了动态仲裁或者手动配置了节点投票新节点加进来后要重新评估投票配置避免出现偶数节点导致仲裁不稳。三节点场景一般问题不大但节点数继续增加时要留意。4. 在新节点上启用 AlwaysOn 并加入可用性组Windows 群集认了新节点接下来才是 SQL Server 自己的事。这一层分两步先在新节点的 SQL Server 实例上把 AlwaysOn 功能打开再把这个实例作为副本加进已有的可用性组。4.1 切换 SQL Server 服务账户并启用 AlwaysOnAlwaysOn 要求 SQL Server 服务账户是域账户或者至少是群集里各节点都能识别的账户。新节点装完 SQL Server 后服务账户可能还是默认的虚拟账户或本地账户需要改过来。操作路径打开 SQL Server 配置管理器或者直接在服务管理器里找到SQL Server(MSSQLSERVER)服务右击属性→登录页签选择账户并输入密码原文写的是密码为服务器密码实际应该是域账户密码确定后重启服务生效。服务账户切好后启用 AlwaysOn。在 SSMS 里右击实例根节点→属性→AlwaysOn 高可用性页签勾选启用 AlwaysOn 可用性组确定。这一步会提示需要重启 SQL Server 服务重启后 AlwaysOn 才真正生效。-- 重启后在新节点上验证 AlwaysOn 是否已启用 SELECT SERVERPROPERTY(IsHadrEnabled) AS IsHadrEnabled, SERVERPROPERTY(HadrManagerStatus) AS HadrManagerStatus;IsHadrEnabled返回 1 才算启用成功HadrManagerStatus返回 1 表示管理器已启动。如果IsHadrEnabled还是 0多半是服务账户没切对或者服务没重启干净。4.2 从主副本发起添加副本启用成功后登录数据库集群侦听 VIP或者直接连主副本在 SSMS 里展开AlwaysOn 高可用性→可用性组右击目标组testgroup1点添加副本。向导里几个关键配置副本服务器输入test209.test.com点连接确认能连上。可用性模式同步提交还是异步提交。只读副本如果对数据新鲜度要求高选同步提交如果只是分担报表、能容忍一点延迟异步提交对主副本压力更小。这次定位是读我一般按业务容忍度选报表场景异步就够。故障转移模式自动还是手动。只读副本通常选手动不参与自动故障转移。可读辅助副本选是并决定是仅读意向还是允许所有连接。报表连接一般用仅读意向配合连接字符串里的ApplicationIntentReadOnly。端点确认镜像端点端口默认 5022在新节点上已监听。4.3 加入后的数据同步与验证副本加进去后可用性组会开始把主副本的数据同步到新节点。同步方式取决于你选的初始数据同步选项如果选自动种子设定SQL Server 2016 支持主副本会直接把数据库种子推过去如果选备份/还原需要你手动在主副本备份、在新节点还原再 join。同步过程中可以查状态-- 在主副本上查看各副本的同步状态 SELECT ag.name AS AGName, ar.replica_server_name AS ReplicaName, drs.synchronization_state_desc AS SyncState, drs.synchronization_health_desc AS SyncHealth, drs.database_state_desc AS DBState 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;SyncState最终要变成SYNCHRONIZEDSyncHealth是HEALTHYDBState是ONLINE。如果长时间停在SYNCHRONIZING看主副本到新节点的端点连通性和日志传输有没有报错。5. 加副本过程中的避坑与排查清单前面按流程走下来理论上能成但实操里翻车点集中在几个地方。这一章把最常见的几条按现象→原因→解决列出来都是血泪经验。5.1 添加节点时验证失败提示网络不可达现象群集管理器添加节点向导跑到验证配置网络项报红提示某节点不可达。原因hosts 没对齐或者新节点和老节点之间防火墙挡了群集通信端口。群集通信除了常规的 RPC还依赖多个动态端口。解决先双向ping主机名确认解析再确认 Windows 防火墙对故障转移群集放行。生产环境如果开了域防火墙策略检查群集相关规则有没有被覆盖。5.2 SSMS 里添加副本找不到新节点现象在新节点上启用了 AlwaysOn但主副本的添加副本向导里输入主机名后连不上或者列表里没有。原因新节点还没加入 Windows 群集或者 SQL Server 服务账户不是域账户导致跨节点认证失败。解决回群集管理器确认test209在节点列表里且状态Up再确认新节点 SQL Server 服务账户和现有节点一致都是域账户。5.3 加副本时报排序规则不一致现象向导走到最后一步报错提示实例排序规则不匹配。原因新节点装 SQL Server 时排序规则没和现有节点对齐。解决这个没法在线改只能重装实例或者用重建系统数据库的方式改排序规则。所以装之前一定要先查SERVERPROPERTY(Collation)。这是最贵的坑重装一次半天没了。5.4 副本加进去了但一直 SYNCHRONIZING现象副本状态长期停在SYNCHRONIZINGSyncHealth不是HEALTHY。原因镜像端点端口不通或者初始数据同步没完成或者主副本日志被截断导致新副本追不上。解决先查端点连通性telnet test209.test.com 5022再看初始同步方式如果是手动备份还原确认还原时用了NORECOVERY并执行了JOIN如果日志链断了重新做一次完整同步。5.5 只读路由没生效报表还是打到主副本现象副本加好了可读也开了但报表连接还是走主副本。原因只读路由Read-Only Routing没配置或者连接字符串没带ApplicationIntentReadOnly。解决在可用性组上配置只读路由 URL把只读副本加进路由列表应用侧连接字符串加ApplicationIntentReadOnly。两者缺一不可。6. 只读路由与副本权重让新节点真正分担读流量副本加进去只是能读要让它真的分担读还得配只读路由和备份优先级。这一步是很多集群加完副本后最容易漏的收尾。只读路由的核心是给可用性组配一个只读路由 URL 列表客户端带ApplicationIntentReadOnly连侦听器时侦听器按列表把连接导向只读副本。配置用 T-SQL-- 在主副本上为可用性组配置只读路由 ALTER AVAILABILITY GROUP [testgroup1] MODIFY REPLICA ON Ntest52.test.com WITH (SECONDARY_ROLE (READ_ONLY_ROUTING_URL NTCP://test52.test.com:1433)); ALTER AVAILABILITY GROUP [testgroup1] MODIFY REPLICA ON Ntest209.test.com WITH (SECONDARY_ROLE (READ_ONLY_ROUTING_URL NTCP://test209.test.com:1433)); -- 指定主副本角色下的只读路由列表按优先级排列 ALTER AVAILABILITY GROUP [testgroup1] MODIFY REPLICA ON Ntest51.test.com WITH (PRIMARY_ROLE (READ_ONLY_ROUTING_LIST (Ntest209.test.com, Ntest52.test.com)));READ_ONLY_ROUTING_URL里的端口是 SQL Server 实例端口默认 1433命名实例要换成实际端口。READ_ONLY_ROUTING_LIST的顺序就是优先级我把新节点test209放前面让它优先接读流量test52兜底。这样报表连接会先打到新节点老辅助副本压力立刻下来。配完用连接字符串验证Servertcp:test51.test.com,1433;DatabaseYourDB;Integrated SecuritySSPI;ApplicationIntentReadOnly;连上后查SELECT SERVERNAME如果返回test209说明只读路由生效了。这一步我每次加完副本都强制走一遍因为路由不配副本就是白加。备份优先级也顺手调一下。新节点如果磁盘和 IO 扛得住可以把它的备份优先级调高让备份任务落到它身上进一步减轻主副本和老辅助副本的负担ALTER AVAILABILITY GROUP [testgroup1] MODIFY REPLICA ON Ntest209.test.com WITH (BACKUP_PRIORITY 60);优先级数值越大越优先主副本默认 50辅助副本默认 50新节点设 60 就会优先接备份。设完记得观察一段时间确认新节点的 IO 和同步延迟没被备份拖垮。从那以后我每次给 AlwaysOn 加副本都强制按hosts 对齐 → 群集验证 → 服务账户 → 排序规则核对 → 只读路由这个顺序走一遍少一步后面就得返工。希望帮到你。本文还有配套的精品资源点击获取