简介针对在 SQL Server 2016 Always On 集群中新增数据库节点的需求这份由亲测实践整理而成的操作文档可供数据库管理员和运维人员直接参考。资源为单个 docx 文件压缩包约 1.92MB内含大量界面截图、逐步操作说明和关键配置示例版式清晰适合按图索骥执行。已有 102 人学习/下载适用于在生产或测试环境中向现有可用性组平滑加入新副本的场景这类集群扩容操作在运维中较为常见。内容从环境角色规划入手先梳理主副本、辅助副本及计划添加副本的 IP、主机名和读写归属再依次覆盖新节点安装 SQL Server、启用故障转移群集功能、修改 hosts 文件、将节点加入 Windows 故障转移群集、开启 Always On 并添加到可用性组等完整链路。每个环节都有对应截图与实测说明能帮助 DBA 提前识别常见疏漏减少扩容操作风险。1. 往 Always On 集群里加只读副本不是跑完向导就完事在 SQL Server 2016 的 Always On 集群里加一个新节点表面上是个标准的“添加副本”向导真上手你会发现它牵扯 Windows 故障转移集群的节点成员身份、SQL Server 服务的启动账号、端点权限、同步模式任何一个环节没对齐结果都是副本一直显示“未同步”。这篇用一个三节点环境来拆主副本负责写test51、现有辅助副本负责读test52、第三个节点test209计划作为新只读副本加入 testgroup1 可用性组重点落在“加入 Windows 集群、开启 Always On、进可用性组”三步的实操细节和踩坑记录上。适合 DBA 和运维工程师照着复现也适合第一次在已有集群上动刀、怕把生产搞挂的人提前看清边界。2. 加入 Windows 故障转移集群这一步错后面全崩2.1 为什么必须先把 Windows 集群搞定Always On 可用性组是跑在 Windows 故障转移集群WSFC之上的不是 SQL Server 自己独立维护高可用。SQL Server 2016 的 Always On 依赖 WSFC 提供健康检测、仲裁投票、故障转移决策。新节点如果没有先加入 WSFC即便 SQL Server 装好了、服务也开着打开 SSMS 里“启用 Always On 可用性组”的选项也是灰的——因为在操作系统层它还不是集群的法定成员。这个设计经常被刚上手的人忽略。有人直接在新节点上装完 SQL Server 就跑去“添加副本”结果要么连不上、要么提示集群节点不是可用性组的候选节点。根因就在 Windows 集群层没通过。所以顺序必须是装 SQL Server → 加故障转移集群功能 → 改 hosts → 加节点进 WSFC → 启用 Always On → 加副本。跳一步后面就是无尽的玄学报错。2.2 故障转移集群功能怎么开在新节点上安装 SQL Server 软件这一步按常规来实例名、排序规则、目录最好跟现有节点保持一致否则后面维护要分两套路径。装完之后先别碰 SQL Server 配置先打开“服务器管理器”点“添加角色和功能”一路下一步到“功能”页勾选“故障转移群集”。这里有个容易漏的点弹出的对话框会提示“添加功能”确认必须点掉否则功能没装全。故障转移群集依赖一些底层功能组件比如“远程服务器管理工具”里的群集管理单元不一起装上的话后续在集群管理器里看不到对应操作项。装完功能后重启一次系统再进“故障转移群集管理器”确认能正常打开别急着操作。2.3 hosts 文件双端都要改少一个就找不到机器修改 hosts 是一个看着简单、错起来很隐蔽的环节。现有节点test51、test52的C:\Windows\System32\drivers\etc\hosts里要添加新节点的 IP 和主机名映射10.106.210.209 test209.test.com同时新节点自己的 hosts 里要把全部节点的 IP 和主机名都加上10.106.210.51 test51.test.com 10.106.210.52 test52.test.com 10.106.210.209 test209.test.com为什么不依赖 DNS很多内网环境的 DNS 解析策略或安全组策略会阻断 SQL Server 和集群服务对主机名的直接解析尤其在多网卡、防火墙分段的环境里hosts 是让集群通信走内网管理段的最直接手段。改完 hosts 建议在命令行执行ping test209.test.com确认解析结果指向正确的 IP同时确认集群节点之间 TCP 445、UDP 3343集群通信端口能通。2.4 把新节点加进 WSFC连接和验证细节在现有主节点上打开“服务器管理器”点“工具”→“故障转移群集管理器”。如果管理器打开后并没有连到你现有的集群先右键“故障转移群集管理器”选择“连接到群集”输入现有集群的名称比如 testcluster 或你实际的名字确认连上了再继续。右侧操作栏里点“添加节点”输入新节点的主机名 test209点“添加”然后“下一步”。验证界面会让你逐个检查存储、网络、集群配置这些验证不一定全部通过才能加但网络部分的错误要看清楚——如果“网络绑定”或“集群通信”报了 ERROR多半是 hosts 没改对或防火墙把集群端口拦了解决完再继续。验证通过后向导会显示“节点已添加”此时在集群管理器的“节点”目录下应该能看到 test209 显示为“运行”。如果这里只显示“暂停”或“不可用”先别进下一步检查 Windows 事件日志里 Cluster 服务的报错通常能直接看到问题。提示添加节点这一步是在 Windows 集群层面操作跟 SQL Server 没关系失败时不要跑去翻 SQL Server 错误日志方向错了查半天都是空的。3. 打开 Always On 开关账号、权限和服务重启三件事3.1 启用 Always On 可用性组前的系统前置条件Windows 集群就绪后新节点的 SQL Server 需要开启 Always On 功能。这一步在很多文档里被一句话带过但它牵扯 SQL Server 服务的启动账号、集群服务账号、权限分配三件事。SQL Server 服务账号必须对 WSFC 有访问权限而且该账号必须能读取集群对象。常见做法是让所有 SQL Server 实例使用同一个域账号运行服务这样加入 WSFC 后权限天然是一致的。如果新节点用了不同的本地账号或服务账号集群永远认为这个节点的 SQL Server 实例没有权限参与可用性组。另外一点如果 WSFC 是多节点的SQL Server 服务账号还要有对集群名称对象CNO的权限因为可用性组会用到 WSFC 的虚拟名称。这一步通常由加域时的配置完成但如果你维护的集群不在域环境里或者账号不是标准域账号就要手工确认。3.2 打开开关的具体操作在 SQL Server 配置管理器里找到 SQL Server(MSSQLSERVER) 服务右键属性切到“AlwaysOn 高可用性”页勾选“启用 AlwaysOn 可用性组”。注意这之后系统会要求重启 SQL Server 服务。重启后别急着做任何事先用以下命令确认开关确实生效SELECT servicename, is_alwayson_enabled FROM sys.dm_server_services WHERE servicename LIKE SQLSERVER%正常情况is_alwayson_enabled应该返回 1。如果返回 0说明勾选没生效多半还是服务账号或集群权限的问题这时候去事件日志里搜“AlwaysOn”相关条目会比瞎猜有用得多。提示SQL Server 2016 的 Always On 只能启用一个可用性组吗不是一个实例可以承载多个可用性组但每个副本只能属于一个可用性组。多组场景下心跳网络和只读路由的配置会复杂一个量级本文先不展开。3.3 服务账号密码变更的连锁影响项目正文里提到“输入密码后提示重启服务生效”这里说的其实是 SQL Server 服务的登录密码。如果你的 SQL Server 服务是用域账号运行的并且密码修改过一定要先确认集群里所有 SQL Server 节点都更新了服务账号密码否则会出现一种诡异情况新节点服务起来了但 WSFC 检测到这个 SQL Server 实例“不健康”可用性组添加副本时会直接失败。我的建议是在改服务账号密码前先在每个节点上用 SQL Server 配置管理器更新密码再重启 SQL Server 服务。顺序不能乱更不能只改一个节点。密码更新后最好执行一次集群验证“故障转移群集管理器”里右键集群名称选择“验证群集”完整跑一遍确认没有服务账号相关的告警。4. 把新副本添进可用性组向导之外的真实工作4.1 添加副本向导的完整流程完成前面的准备后登录数据库集群侦听 VIP打开 SSMS 的对象资源管理器展开“AlwaysOn 高可用组”→“可用性组”右键目标可用性组这里是 testgroup1选择“添加副本”。向导会要求指定副本实例。填入 test209.test.com 的 SQL Server 实例名点“连接”然后你会看到可用性组当前副本列表和新增副本的同步模式选择。这里有两个模式同步提交Synchronous和异步提交Asynchronous。对只读副本来说通常用异步提交就够了——因为它不承担故障转移责任只提供读负载扩展。但如果你的业务要求只读副本的数据延迟尽量小且在故障转移时能转正那可以选同步提交。注意同步提交会拖累主库提交性能每个事务要等辅助副本确认写入延迟升高是必然的。4.2 端点权限与连接字符串添加副本时向导会自动创建可用性组端点但有个常见的坑如果新节点上 SQL Server 之前没配置过数据库镜像端点需要手工创建或让向导完成。向导通常会创建端点和授权但如果你遇到“无法访问端点”的报错就需要检查以下内容SELECT name, type_desc, port, state_desc FROM sys.tcp_endpoints WHERE type 2state_desc应为 STARTED。如果为 STOPPED 或 DISABLED需要手动开启。另外端点权限非常关键——所有副本节点上的账号必须有 CONNECT 权限。常见做法是给所有可用性组成员实例的启动账号都赋 Connect 权限执行以下命令GRANT CONNECT ON ENDPOINT::Hadr_endpoint TO [YOURDOMAIN\sqlservice]如果这里漏了副本加进去后会出现反复“连接失败”“同步挂起”的日志且状态栏里看不到具体原因非常折磨人。然后是连接字符串。只读副本的连接字符串ApplicationIntent 必须设为 ReadOnlyServertcp:listener.test.com,1433;DatabaseYourDB;ApplicationIntentReadOnly;有人把ApplicationIntent写成ReadOnly之外的任意值连接会被路由到主副本读负载没减轻自己还觉得配置没问题——这是用监听器做读写分离时最常见的翻车点。4.3 数据同步初始同步还是备份还原添加副本时向导会问“数据同步选项”有三个选择完整Full、仅备份Backup only、跳过Skip。如果你在生产库上选“完整”向导会先做一个完整备份然后在新副本上还原并加入可用性组。对大库比如超过 1TB来说这个操作耗时极长而且向导在还原时会占用大量磁盘 IO 和网络带宽可能拖垮主库性能。我的经验是大库场景直接选“跳过”手工做备份和日志还原最后以JOIN方式加入可用性组。具体的做法是在主库上执行完整备份再备份当前日志把备份文件复制到新节点在新节点上还原为NORECOVERY状态然后手工执行ALTER AVAILABILITY GROUP testgroup1 JOIN;然后把数据文件加入可用性组ALTER DATABASE YourDB SET HADR AVAILABILITY GROUP testgroup1;这样做的优势是时间点完全可控而且不会对主库并发造成不可预期的压力。缺点是操作多了两步需要你手动保证日志链衔接完整——中间丢一个日志备份同步就断了。4.4 只读路由配置只读副本加进去后要让它真正承担读流量还得配置只读路由。这步是很多人到最后才发现的坑副本状态显示“已同步”但业务连接永远打不到它身上。配置路由需要更新可用性组实现在主副本上执行ALTER AVAILABILITY GROUP [testgroup1] MODIFY REPLICA ON Ntest51.test.com WITH (SECONDARY_ROLE(ALLOW_CONNECTIONS READ_ONLY)); ALTER AVAILABILITY GROUP [testgroup1] MODIFY REPLICA ON Ntest51.test.com WITH (PRIMARY_ROLE(READ_ONLY_ROUTING_LIST (test209.test.com,test52.test.com)));第一句允许辅助副本接受只读连接第二句告诉主副本路由优先级先发给 test209再发给 test52。如果只配了第一句忘了第二句连接串就找不到目标。5. 常见问题与避坑记录五条高频翻车现象5.1 添加副本时提示“无法连接到副本”现象向导测试连接报错提示“无法连接到副本实例”错误 1801 或 18456。原因最常见是 hosts 没配好或 SQL Server 远程连接未开启。SQL Server 2016 默认未启用 TCP/IP 协议的情况很多见如果新节点只是装完系统、SQL Server 配置管理器里没启动 TCP/IP连接必然失败。解决先在配置管理器里确认 TCP/IP 已启用并监听固定端口默认 1433然后 telnet 测一下通不通telnet test209.test.com 1433。然后再试一次向导。另检查防火墙允许入站 TCP 1433。5.2 副本显示“未同步”同步健康状态为“Not Synchronizing”现象副本成功加入但仪表盘上一直是“Not Synchronizing”数据不追平。原因日志备份和还原链有缺口或者可用性组端点的权限不对。尤其是手工备份还原后没跟上后续日志备份同步起不来。解决先看看sys.dm_hadr_database_replica_states里synchronization_state_desc值如果是NOT SYNCHRONIZING通常要重新做一次日志备份并RESTORE ... WITH NORECOVERY来续上链别指望它能自愈。5.3 加副本时向导没有“完整”选项现象数据同步选项里“完整”是灰的只能选“跳过”或“仅备份”。原因新实例上 SQL Server Agent 没启用或者备份权限不足。完整选项依赖 SQL Server Agent 执行备份作业。解决启动新节点 SQL Server Agent给它配置为自动启动。如果是权限问题给执行向导的登录账号授予 Backup Operator 或 sysadmin 角色。5.4 加入 WSFC 后节点显示“暂停”或“不可用”现象集群管理器里能看到节点但状态一直是 Paused 或 Up 但没有上下文。原因节点加进去之后集群服务没能和节点上的 Cluster Service 完成握手可能是防火墙拦截了 UDP 3343也可能是该节点上有多个网卡且网络配置没选对。解决在集群管理器“网络”里确认新节点的网络适配器被识别为“集群通信”允许的网卡如果不确定用 PowerShell 查看Get-ClusterNetwork的 Role 字段。或者把节点状态手动恢复右键节点→“恢复”。5.5 只读副本连接到了主库现象连接串明明指定了只读SSMS 里却显示连到了主副本。原因只读路由没配或ApplicationIntent没设置。还有种可能是监听器在 DNS 层面没有对新副本注册。解决确认两段路由 SQL 都执行过并用 PowerShell 查看(Get-ClusterResource 可用性组监听器).State确认监听器是否正常。连接串里务必带上ApplicationIntentReadOnly而且不能用 IP 直连要连可用性组监听器名称。提示上述五条如果全排查完状态还是不对建议直接在目标节点上看 SQL Server 错误日志尤其是HADR相关的条目。Always On 的日志虽然冗长但八成问题在日志里能找到第一现场。6. 验证与收尾用动态管理视图验收一个“真正可用”的只读副本副本加入后最有用的事情不是看 UI 上那个绿色对勾而是用几条系统视图把自己确认到位的状态固化下来。我每次配完都会跑一遍这套验证逻辑确认后才算真正交付。首选在主副本上看sys.dm_hadr_availability_replica_statesSELECT ar.replica_server_name, ar.availability_mode_desc, ar.secondary_role_allow_connections_desc, ars.role_desc, ars.operational_state_desc, ars.connected_state_desc, ars.synchronization_health_desc FROM sys.dm_hadr_availability_replica_states ars JOIN sys.availability_replicas ar ON ar.replica_id ars.replica_id关注secondary_role_allow_connections_desc是否为READ_ONLYoperational_state_desc是否 ONLINEconnected_state_desc是否 CONNECTED。三条都符合副本才是真正可用不然只能是“纸面同步”。再在辅助副本上确认数据库同步进度SELECT db_name(database_id) AS database_name, synchronization_state_desc, synchronization_health_desc, last_hardened_lsn, end_of_log_lsn FROM sys.dm_hadr_database_replica_states WHERE is_local 1last_hardened_lsn应该持续增长跟主库差距保持稳定。如果你看到last_hardened_lsn长期不动说明日志传输已经中断复现 5.2 的方案解决。最后实际做一次读连接测试确认 ApplicationIntent 被正确路由SELECT SERVERNAME, HOST_NAME()如果查出来是 test209说明只读路由生效了。到这里一个真正可以接读流量的新副本才算落地完整。四个月前我第一次在模拟项目X 上做同样操作时跳过 hosts 直接加 WSFC结果测试环境折腾了大半个工作日节点反复“添加失败”最后发现 DNS 解析串到了别的网段。从那以后我每次进集群操作前都强制先在一个文本文件里确认好节点名称、IP 映射、防火墙端口三段信息再动任何一个开关。希望这篇能让你在真实环境里少走这段弯路。本文还有配套的精品资源点击获取