前言

在企业域架构 SQL Server AlwaysOn 可用性组运维中，绝大多数 AG 采用 域账号启动 SQL 服务 + Windows Kerberos 认证架构。一旦旧域账号存在密码泄露、权限冗余、账号生命周期到期，就必须完成「旧账号下线、新账号全量替换」的高危变更。

该操作属于生产高危运维动作，大量 DBA 长期踩坑，核心误区集中在以下 5 点：

1、误以为「改密码需要重启、换账号不用重启」；

2、误用 services.msc 修改服务账号，导致 AG 断连、备份异常、代理作业报错；

3、维护过渡期提前删除旧服务账号登录名，引发主从同步中断；

4、无法区分租约超时、会话超时、健康检查超时、SPN、凭据缓存底层机制；

5、核心认知错误：认为端点权限实时校验，或仅第一次连接校验一次永远放行。

本文完整拆解 Windows 域认证 AG 底层通信机制、改密码/换账号本质区别、删除登录是否瞬时断主从、生产级滚动割接流程、全网最全坑点规避，可作为企业标准账号替换运维手册。

一、核心概念

绝大多数 AG 诡异故障，根源都是概念混淆。

对象	端口/范围	通信身份	核心作用
Hadr_endpoint 镜像端点	TCP 5022（跨机器）	SQL 服务启动域账号	主从日志同步、心跳探测、AG 控制消息传输
AG 侦听器	TCP 1433（业务）	应用登录账号	业务读写接入、高可用统一入口
租约 Lease	本机内存、无端口	NT SERVICE 服务 SID	SQL 与 WSFC 群集保活、防脑裂、自动故障转移判定

两条运维铁律：

1、跨机器主从同步（5022 端口） 只认域服务账号；

2、本机群集租约续约 只认服务 SID，和域账号无关。

二、底层原理：改密码不重启、换账号必须重启

该差异由 Windows 两大核心机制决定： 进程访问令牌 Token、 进程凭据缓存 Cache。

1、访问令牌 Access Token

sqlservr 进程启动瞬间，Windows 根据启动账号生成唯一 Token，该令牌 绑定进程终身。Windows 硬性规则： 运行中的进程，无法动态替换账号 Token。

2、进程凭据缓存 Credential Cache

独立于进程 Token，系统内存缓存账号密码，专门用于向域控申请 Kerberos 通行证，支撑跨机器通信鉴权。

3、三种操作本质差异对比

操作场景	Token 是否变更	是否需要重启	底层原理
仅修改密码（同账号）	不变	无需重启	配置管理器刷新内存凭据缓存，不更换进程身份
更换服务账号（账号变更）	重建	必须重启	无法热切换 Token，需重建进程、重加密服务主密钥、更新系统 ACL
services.msc 修改密码	不变	必须重启	仅写入注册表，不刷新内存凭据缓存，属于非法高危操作

重要官方误区纠正：

微软文档提及的「群集被动节点可用 services.msc」 仅适用于 FCI 共享存储群集、仅改密码场景。 AlwaysOn AG 所有节点、所有账号变更，一律只允许使用 SQL 配置管理器。

三、核心高危问题：删除正在使用的服务账号登录名，主从是否立刻断连？

1、最终结论

删除 SQL 服务域账号对应的服务器登录名， 不会立刻断开当前正常存活的 AG 长连接；但只要 AG 会话发生重建，会立即鉴权失败，副本变为 DISCONNECTED，同步彻底中断。

2、为什么不会瞬时断连？

Windows 认证模式 Hadr_endpoint 鉴权机制：

- 长连接存续期间： 不重复校验权限、不查询登录、不二次鉴权

- 仅在「新建 TCP 会话 / 重建 AG 会话」时刻执行完整鉴权

因此在线 DROP LOGIN 瞬间，现有 5022 TCP 通道、AG 会话正常存活，日志可持续传输，无瞬时断连现象。

3、所有会引爆故障的重连场景

任意触发会话重建的动作，都会完整重走鉴权流程，直接爆故障：

1、AG 默认 10 秒会话超时重连（SESSION_TIMEOUT，SQL 副本参数控制）

2、网络抖动、防火墙会话老化、TCP 保活失效

3、SQL 服务重启、Hadr 端点重启

4、AG 手动/自动故障转移

5、Kerberos 通行证过期重新协商（默认 10 小时， 域控 AD 组策略控制，与 SQL 无关）

鉴权失败流程：重新申请通行证 → 解析 Windows SID → 查询 master 登录 → 登录已删除 → 无 CONNECT 权限 → 拒绝连接、副本断连。

4、两层鉴权核心区分

1）Windows 层 Kerberos 校验：操作系统 LSASS 校验通行证签名、有效期、合法性， 完全不看 SQL 登录名，只要通行证合法就放行身份。

2）SQL 引擎层端点权限校验：根据 Windows 传递的 SID 匹配 SQL 登录名，校验端点 CONNECT 权限， 强依赖登录名存在。

核心结论： Windows 认证成功 ≠ AG 连接成功，删除 SQL 登录名照样拒绝主从同步连接。

5、租约机制完全不受影响

删除域账号登录名：

✅ 不影响本机 SQL <> WSFC 租约续约

✅ 本地业务读写完全正常

❌ 仅跨机器主从同步无法新建连接，存量长连接可短暂存活

四、Hadr_endpoint 完整通信流程 + 双向通信原理

4.1、完整 Kerberos 鉴权通信流程（主连从示例）

AG 为双向通信架构，反向从连主链路，执行完全一致的鉴权逻辑：

1、主副本 sqlservr.exe 以自身启动域账号身份，发起对从副本 5022 端点的 TCP 连接；

2、主副本 LSASS 读取内存凭据缓存，向域控 KDC 申请对端 SQL 服务的 Kerberos 通行证；

3、通行证随 SSPI 协商报文、TCP 数据流传输至从副本 Hadr_endpoint；

4、从副本 LSASS 本地解密校验通行证（无需访问域控），解析出发起方 SID；

5、从库 SQL 查询 sys.server_principals，匹配登录并校验端点 CONNECT 权限；

6、校验通过则建立会话、传输重做日志；校验失败则拒绝连接，副本标记 DISCONNECTED。

潜伏重大隐患：AD 修改账号密码后，若未用配置管理器刷新 SQL 凭据缓存，旧通行证未过期时同步正常， 10小时通行证到期续订瞬间批量断同步，属于典型延迟爆发隐形故障。

4.2、为什么 AG 必须双向发起连接？

很多人混淆「日志流向」和「连接发起能力」：日志是主→从单向推送，但连接探测、重建必须双向。

1、同步提交需要反向 ACK 回执：主库推送日志，从库硬化日志后，需要反向回传 LSN 确认包，主库收到回执才提交业务事务；链路断连后，从库必须具备主动重连能力。

2、故障转移角色互换：主从角色切换后，原从变主、原主变从，必须支持反向建连同步，因此所有副本端点默认 ROLE=ALL。

3、双向心跳探测：主从互相 10s Ping 探测链路存活，任意一端超时均判定断连并主动重连。

五、AlwaysOn 三大超时机制完整区分

超时类型	对象	默认值	现象与影响
租约超时 LeaseTimeout	本机 SQL <> WSFC	20s	SQL 进程卡死、无响应触发自动故障转移，与网络无关
会话超时 SessionTimeout	主从副本之间	10s	主从心跳中断、副本断开，不会自动切主
健康检查超时 HealthCheckTimeout	WSFC 检测 SQL 实例健康	30s	通过系统存储过程 sp_server_diagnostics 判定实例卡死、IO 夯、调度异常，触发故障转移

维护必须改为 MANUAL 模式原因：

虽然删登录不影响租约，但重启 SQL、账号变更阶段会出现进程短暂退出、CPU 抖动、redo 恢复卡顿，极易触发租约/健康检查超时。改为手动故障转移，可 杜绝维护窗口计划外自动切主，全程人工可控。

六、生产级 AG 域账号滚动替换完整流程

场景：下线老旧/风险域账号 DOMAIN\OldSvc，全节点迁移至新账号 DOMAIN\NewSvc

阶段1：全节点前置准备（核心：双账号共存）

所有主、从副本统一执行，缺一不可：

1、AD 提前创建新域账号，赋予服务器本地服务登录权限；

2、SQL 全节点创建新登录，新旧账号共存，避免断连；

3、关闭 AG 自动故障转移，规避维护抖动误切换。

-- 创建新域登录
CREATE LOGIN [DOMAIN\NewSvc] FROM WINDOWS;
-- 授予 AG 最小必备权限
GRANT CONNECT ON ENDPOINT::Hadr_endpoint TO [DOMAIN\NewSvc];
GRANT ALTER ANY AVAILABILITY GROUP TO [DOMAIN\NewSvc];
GRANT VIEW SERVER STATE TO [DOMAIN\NewSvc];
-- 修改为手动故障转移（维护保命操作）
ALTER AVAILABILITY GROUP [AG名称]
MODIFY REPLICA ON N'节点名' WITH (FAILOVER_MODE=MANUAL);

阶段2：逐台滚动替换从库账号

单台操作、单台观察，同步完全稳定后再操作下一台，禁止多台同时变更：

1、打开 SQL Server 配置管理器（严禁 services.msc）；

2、修改 SQL 服务登录账号为新域账号；

3、重启 SQL 服务；

4、持续观察，等待副本状态 SYNCHRONIZED、redo 队列持续归零。

同步状态校验脚本（生产标准）

-- 查看全节点同步状态、redo 堆积
SELECT
    ag.name AS AG名称,
    ar.replica_server_name AS 副本节点,
    db.name AS 数据库名,
    drs.redo_queue_size AS redo队列大小_KB,
    drs.redo_rate AS redo速率_KB_s,
    drs.synchronization_state_desc AS 同步状态
FROM sys.availability_groups ag
JOIN sys.availability_replicas ar ON ag.group_id = ar.group_id
JOIN sys.dm_hadr_database_replica_states drs ON ar.replica_id = drs.replica_id
JOIN sys.databases db ON drs.database_id = db.database_id
ORDER BY ag.name, ar.replica_server_name, db.name;
-- 预估 redo 剩余完成时间
SELECT
    ag.name AS AG名称,
    ar.replica_server_name AS 副本节点,
    db.name AS 数据库名,
    drs.redo_queue_size,
    drs.redo_rate,
    CASE WHEN drs.redo_rate > 0 THEN drs.redo_queue_size / drs.redo_rate ELSE 0 END AS 预估剩余秒数
FROM sys.availability_groups ag
JOIN sys.availability_replicas ar ON ag.group_id = ar.group_id
JOIN sys.dm_hadr_database_replica_states drs ON ar.replica_id = drs.replica_id
JOIN sys.databases db ON drs.database_id = db.database_id;

判定标准： synchronization_state_desc = 'SYNCHRONIZED' 且 redo_queue_size 持续稳定为 0KB。

此时中间状态：主库旧账号、从库新账号，双登录共存保障双向通信正常。

阶段3：手动故障转移切换主节点

将 AG 主副本手动切换至已完成新账号替换、同步稳定的节点。

阶段4：替换原旧主节点账号

原主节点变为从节点，重复阶段2操作：改账号、重启、等待同步归零。

阶段5：SPN 迁移（解决 SSPI 上下文报错）

更换服务账号后，旧账号会残留 MSSQLSvc 服务主体名称，新账号无对应 SPN，会导致 Kerberos 协商失败、 Cannot generate SSPI context 报错、AG 节点通信异常。

操作动作：

1、清理旧账号残留重复 SPN；

2、为新域账号注册实例、FQDN、侦听器全套 SPN；

3、清理域内重复 SPN 冲突。

阶段6：稳定后清理旧账号（严禁提前操作）

1、删除数据库老的登录名 (DOMAIN\OldSvc)

全节点切换完成、观察稳定、故障转移演练正常后，再清理旧账号：

-- 转移端点所有者（必须先执行，否则无法删除旧登录）
ALTER AUTHORIZATION ON ENDPOINT::Hadr_endpoint TO [DOMAIN\NewSvc];
-- 全节点删除旧登录
DROP LOGIN [DOMAIN\OldSvc];

删除完成后，恢复 AG 自动故障转移模式，变更收尾。

2、删除服务器老的域账号 (DOMAIN\OldSvc)

七、高危避坑红线总结

❌ 过渡期严禁删除旧登录：任意重连动作直接断同步，生产不可赌概率

❌ 禁止用 services.msc 修改 AG 账号：仅改注册表，不刷新缓存、不更新ACL、不维护SPN，遗留大量隐形故障

❌ 禁止混淆租约、会话、健康检查三套超时机制

❌ 禁止只改单节点登录：master 库不跟随 AG 同步，所有节点必须独立配置

✅ 删登录不瞬时断连，但重连必爆故障，生产必须双账号共存滚动切割

✅ 所有 AG 账号变更，仅允许使用 SQL 配置管理器

八、全文最终核心总结

1、同账号改密码无需重启、更换账号必须重启，由 Windows 进程 Token 和凭据缓存机制硬性决定；

2、删除服务账号登录不会中断存量 AG 长连接，仅会话重建时触发鉴权失败断同步；

3、租约机制依赖服务 SID，与域账号登录无关，删登录不影响群集保活；

4、AG 鉴权分两层：Windows 只管通行证合法，SQL 只管登录权限，缺一不可；

5、账号割接必须新旧登录全节点共存，稳定后再清理旧账号、迁移SPN；

6、域环境 AG 强依赖 Kerberos，密码/账号不同步会产生大量延迟性、间歇性隐形故障。

ITPub博客

SQL Server Always On 域服务账号滚动替换完整实战与底层原理

前言