企业官网建设流程全解析

简介：这份文档面向 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.com（10.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 改漏。这次的环境是这样：

新节点定位是只读副本，所以它不需要参与写，但必须和主副本保持同步。这里有个容易被忽略的点：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.txt，Windows 默认隐藏扩展名，很容易踩这个坑。

3. 把新节点接进 Windows 故障转移群集

hosts 通了之后，才轮到群集层面接纳新节点。这一步在群集当前的主节点上操作，走的是故障转移群集管理器。整个过程本质是让群集做一次"节点验证"，验证通过才会正式把新机器纳入群集成员。

3.1 从群集管理器发起"添加节点"

在群集当前主节点上打开服务器管理器，点"工具"→"故障转移群集管理器"。如果管理器打开后没自动连上群集，右击左侧根节点"故障转移群集管理器"，选"连接到群集"，输入或选择现有群集名。

连上后，在右侧"操作"面板里点"添加节点"，进入添加节点向导。第一步是选择要加入的服务器，输入新节点的主机名test209.test.com，点"添加"把它挪到已选列表，再点"下一步"。

3.2 验证配置这一步别跳过

向导接下来会问是否运行"验证配置"。这里有个实操取舍：正式环境建议跑完整验证，它会检查网络、存储、系统配置等一整套项目，能提前暴露 hosts 没通、防火墙挡了、版本不一致之类的问题。如果只是测试环境想快，可以选"不运行验证"，但生产上我一般强制跑一遍。

验证里最常挂的两项：

• 网络：如果新节点和老节点之间某些网段不通，或者 hosts 没对齐，这里会红。
• 系统配置：如果新节点没装故障转移群集功能，或者 SQL Server 版本/排序规则不一致，这里会提示。

验证通过后，向导会把新节点正式加入群集，完成后在"节点"列表里能看到test209。

3.3 加入后确认群集成员状态

加完别急着走，回到群集管理器确认一下：

# 在群集任意节点上以管理员身份运行，查看群集节点状态 Get-ClusterNode | Format-Table Name, State, NodeWeight -AutoSize

State应该是Up，NodeWeight默认是 1（参与投票）。如果新节点显示Down或者权重异常，先别往下走，回头查群集服务和网络。这一步确认干净了，SQL Server 层面才有意义。

注意：如果群集开了动态仲裁或者手动配置了节点投票，新节点加进来后要重新评估投票配置，避免出现偶数节点导致仲裁不稳。三节点场景一般问题不大，但节点数继续增加时要留意。

4. 在新节点上启用 AlwaysOn 并加入可用性组

Windows 群集认了新节点，接下来才是 SQL Server 自己的事。这一层分两步：先在新节点的 SQL Server 实例上把 AlwaysOn 功能打开，再把这个实例作为副本加进已有的可用性组。

4.1 切换 SQL Server 服务账户并启用 AlwaysOn

AlwaysOn 要求 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，点"连接"确认能连上。
• 可用性模式：同步提交还是异步提交。只读副本如果对数据新鲜度要求高，选同步提交；如果只是分担报表、能容忍一点延迟，异步提交对主副本压力更小。这次定位是读，我一般按业务容忍度选，报表场景异步就够。
• 故障转移模式：自动还是手动。只读副本通常选手动，不参与自动故障转移。
• 可读辅助副本：选"是"，并决定是"仅读意向"还是"允许所有连接"。报表连接一般用"仅读意向"，配合连接字符串里的ApplicationIntent=ReadOnly。
• 端点：确认镜像端点端口（默认 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最终要变成SYNCHRONIZED，SyncHealth是HEALTHY，DBState是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

现象：副本状态长期停在SYNCHRONIZING，SyncHealth不是HEALTHY。

原因：镜像端点端口不通，或者初始数据同步没完成，或者主副本日志被截断导致新副本追不上。

解决：先查端点连通性telnet test209.test.com 5022；再看初始同步方式，如果是手动备份还原，确认还原时用了NORECOVERY并执行了JOIN；如果日志链断了，重新做一次完整同步。

5.5 只读路由没生效，报表还是打到主副本

现象：副本加好了，可读也开了，但报表连接还是走主副本。

原因：只读路由（Read-Only Routing）没配置，或者连接字符串没带ApplicationIntent=ReadOnly。

解决：在可用性组上配置只读路由 URL，把只读副本加进路由列表；应用侧连接字符串加ApplicationIntent=ReadOnly。两者缺一不可。

6. 只读路由与副本权重：让新节点真正分担读流量

副本加进去只是"能读"，要让它"真的分担读"，还得配只读路由和备份优先级。这一步是很多集群加完副本后最容易漏的收尾。

只读路由的核心是给可用性组配一个只读路由 URL 列表，客户端带ApplicationIntent=ReadOnly连侦听器时，侦听器按列表把连接导向只读副本。配置用 T-SQL：

-- 在主副本上为可用性组配置只读路由 ALTER AVAILABILITY GROUP [testgroup1] MODIFY REPLICA ON N'test52.test.com' WITH (SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://test52.test.com:1433')); ALTER AVAILABILITY GROUP [testgroup1] MODIFY REPLICA ON N'test209.test.com' WITH (SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://test209.test.com:1433')); -- 指定主副本角色下的只读路由列表，按优先级排列 ALTER AVAILABILITY GROUP [testgroup1] MODIFY REPLICA ON N'test51.test.com' WITH (PRIMARY_ROLE (READ_ONLY_ROUTING_LIST = (N'test209.test.com', N'test52.test.com')));

READ_ONLY_ROUTING_URL里的端口是 SQL Server 实例端口，默认 1433，命名实例要换成实际端口。READ_ONLY_ROUTING_LIST的顺序就是优先级，我把新节点test209放前面，让它优先接读流量，test52兜底。这样报表连接会先打到新节点，老辅助副本压力立刻下来。

配完用连接字符串验证：

Server=tcp:test51.test.com,1433;Database=YourDB;Integrated Security=SSPI;ApplicationIntent=ReadOnly;

连上后查SELECT @@SERVERNAME，如果返回test209，说明只读路由生效了。这一步我每次加完副本都强制走一遍，因为路由不配，副本就是白加。

备份优先级也顺手调一下。新节点如果磁盘和 IO 扛得住，可以把它的备份优先级调高，让备份任务落到它身上，进一步减轻主副本和老辅助副本的负担：

ALTER AVAILABILITY GROUP [testgroup1] MODIFY REPLICA ON N'test209.test.com' WITH (BACKUP_PRIORITY = 60);

优先级数值越大越优先，主副本默认 50，辅助副本默认 50，新节点设 60 就会优先接备份。设完记得观察一段时间，确认新节点的 IO 和同步延迟没被备份拖垮。

从那以后我每次给 AlwaysOn 加副本，都强制按"hosts 对齐 → 群集验证 → 服务账户 → 排序规则核对 → 只读路由"这个顺序走一遍，少一步后面就得返工。希望帮到你。

本文还有配套的精品资源，点击获取