排查SQL Server Always On问题
本文可帮助你解决有关SQL Server上Always On配置的常见问题。
注意
有关本文的引导性演练体验,请参阅排查SQL Server Always On问题。
原始产品版本:SQL Server 2012 Enterprise、SQL Server 2014 Enterprise、SQL Server 2016 Enterprise
原始 KB 编号: 10179
重要说明
Microsoft CSS 数据表明,很大一部分客户问题以前通常在已发布的 CU 中得到解决,但未主动应用,因此建议在 CU 可用时进行主动安装。 有关详细信息,请参阅宣布更新SQL Server增量服务模型 (ISM) 。
若要检查可能适用于你的版本的最新 OU,请参阅如何确定SQL Server及其组件的版本、版本和更新级别。
可以在Always On可用性组故障排除和监视指南中查看用于故障排除和监视Always On可用性组的有用工具,详细了解可用于诊断不同类型的问题和监视可用性组的工具。 本指南还包含本引导演练中可能未涵盖的其他方案。
Always On可用性组文档的父节点,并针对各种问题提供了一站式参考,请参阅Always On可用性组 (SQL Server) 。
我需要有关设置和配置Always On可用性组的指针
如果要查找有关设置Always On配置的文档,请参阅以下文档:
入门Always On可用性组 (SQL Server) - 本文档提供了有关可用性组和设置的许多问题的答案。 按照本文中的所有步骤操作,查看Always On可用性组的先决条件、限制和建议 (SQL Server) 将有助于防止在环境中设置和维护可用性组时可能会遇到的许多问题。
其他资源
如果此信息没有帮助,请参阅有关Always On可用性组的详细信息。
配置Always On可用性组时遇到问题
典型的配置问题包括Always On可用性组已禁用、帐户配置不正确、数据库镜像终结点不存在、终结点无法访问 (SQL Server 错误 1418) 、不存在网络访问、联接数据库命令失败 (SQL Server 错误 35250) 。 有关排查这些问题的帮助,请查看以下文档:
排查Always On可用性组配置 (SQL Server) 问题
其他链接: 修复:尝试创建多个可用性组时出现错误 41009
如果问题仍然存在,请参阅有关Always On可用性组的详细信息。
我遇到了侦听器配置问题 (19471、19476 和其他错误)
客户遇到的最常见的配置问题之一是创建可用性组侦听器。 这些错误类似于以下内容:
-
消息 19471,级别 16,状态 0,第 2 行 WSFC 群集无法使 DNS 名称为“”的网络名称资源联机。 DNS 名称可能已被采用或与现有名称服务冲突,或者 WSFC 群集服务可能未运行或无法访问。 使用其他 DNS 名称解决名称冲突,或检查 WSFC 群集日志了解详细信息。
-
消息 19476,级别 16,状态 4,第 2 行尝试为侦听器创建网络名称和 IP 地址失败。 WSFC 服务可能未运行,或者在其当前状态下无法访问,或者为网络名称和 IP 地址提供的值可能不正确。 检查 WSFC 群集的状态,并向网络管理员验证网络名称和 IP 地址。
大多数时候,导致上述消息的侦听器创建失败是由于缺少 Active Directory 中群集名称对象 (CNO) 创建和读取侦听器计算机对象的权限。 若要解决此问题,请查看以下文章:
如果问题仍然存在,请参阅有关Always On可用性组的详细信息。
自动故障转移未按预期工作
如果注意到自动故障转移在测试期间或在生产环境中均未按预期工作,请参阅:排查 SQL Server 2012 Always On 环境中的自动故障转移问题。
指定时间段内最大故障配置不当是导致主要服务器无法自动故障转移到辅助数据库的主要原因之一。 此设置的默认值为 N-1,其中 N 是副本数。 有关详细信息,请参阅 故障转移群集 (组) 最大故障数限制。
如果问题仍然存在,请参阅有关Always On可用性组的详细信息。
连接到Always On可用性组时遇到问题
在 SQL Server 2012 中为Always On可用性组配置可用性组侦听器后,可能无法从应用程序对侦听器执行 ping 操作或连接到该侦听器。 你可能会收到类似于以下内容的错误:
Sqlcmd:错误:Microsoft SQL Native Client:登录超时已过期。
若要排查此错误和类似错误,请查看以下内容:
更多信息链接:
- 更新引入了对 SQL Server 2012 或更高版本中的Always On功能的支持,以 the.NET Framework 3.5 SP1
- SQL Server多子网群集 (SQL Server)
如果问题仍然存在,请参阅有关Always On可用性组的详细信息。
在 Azure VM (IaaS) 中配置Always On可用性组时遇到问题
由于侦听器配置不当,出现了许多与Always On相关的问题。 如果与侦听器的连接出现问题,
请务必阅读 ILB 侦听器的所有限制,并遵循以下文章中所述的所有步骤,并特别注意 PowerShell 脚本中的依赖项配置、IP 地址和各种其他参数。
如果不确定,可能需要根据上述文档删除并重新创建侦听器。
如果最近将 VM 移到了其他服务,或者 IP 地址发生了更改,则需要更新 IP 地址资源的值以反映新地址,并且需要为 AG 重新创建负载均衡的终结点。 可以使用 或
Set
命令更新 IP 地址Get
,如下所示:Get-ClusterResource "IPResourceName" | Set-ClusterParameter -name Address -value "w.x.y.z"
建议的文档:
如果问题仍然存在,请参阅有关Always On可用性组的详细信息。
从主要服务器故障转移到辅助数据库需要很长时间,反之亦然
自动故障转移或计划内手动故障转移后,不会丢失可用性组上的数据,你可能会发现故障转移时间超出了恢复时间目标, (RTO) 。 若要排查原因和潜在解决方法,请参阅 故障排除:可用性组超出 RTO。
如果问题仍然存在,请参阅有关Always On可用性组的详细信息。
主副本上的更改未反映在或复制到辅助副本的速度较慢
你可能会注意到,主要副本 (replica) 上的更改不会及时传播到辅助数据库。 若要排查并解决这些问题,请尝试以下操作:
对于 SQL Server 2012 和 SQL Server 2014 环境,请参阅修复:当磁盘对 SQL Server AG 和 Logshipping 环境中的主要和辅助副本 (replica) 日志文件具有不同的扇区大小时,同步速度缓慢。
在群集管理员中检查辅助节点是否处于“已暂停”状态。
如果问题仍然存在,请参阅有关Always On可用性组的详细信息。
如何管理 AG 数据库的事务日志大小
可以通过在主服务器或辅助服务器上配置常规备份来减小事务日志大小。
有关其他信息,请查看以下主题:
如果此信息没有帮助,请参阅有关Always On可用性组的详细信息。
主服务器或辅助服务器处于“正在解析”状态,或者遇到意外故障转移
检查系统和应用程序事件日志中是否存在硬件问题和其他错误,并与供应商合作进行修复。
如果使用虚拟机,检查其知识库,以查看是否有最近报告的问题可能导致此问题。 例如, 在某些情况下,ESXi (2039495) VMXNET3 vNIC 上的来宾操作系统级别的大型数据包丢失 会导致 AG 配置出现问题。
详细信息:
如果问题仍然存在,请参阅有关Always On可用性组的详细信息。
无法使资源联机
通过查看 SQL ErrorLog 中的消息来检查数据库是否花费了很长时间才能恢复。
如果问题仍然存在,请参阅有关Always On可用性组的详细信息。
常见问题解答
是否可以为一个可用性组使用两个侦听器?
是的,可以为同一可用性组设置多个侦听器。 请参阅 如何为同一可用性组创建多个侦听器 (Goden Yao) 。
是否可以将单独的 NIC 卡用于始终启用流量和客户端连接?
是的,可以为Always On流量提供专用 NIC 卡。 请参阅 配置可用性组以在专用网络上进行通信。
哪些版本支持Always On故障转移群集实例?
SQL Server联机丛书中的本主题包含详细信息:SQL Server 2016 的版本和支持的功能。
在群集的所有节点上发生故障时如何恢复?
在哪里可以找到 AG 配置中对分布式事务的支持信息?
请参阅 事务 - 可用性组和数据库镜像。
如何更新Always On配置?
如何将已启用 TDE (透明数据加密) 的数据库添加到 AG 配置?
若要将已启用 TDE 的数据库添加到 AG,请参阅如何为 TDE 数据库配置Always On。
如何配置警报以检查辅助数据库是否落后于主数据库?
可以使用以下脚本:
SELECT ag.name AS ag_name, ar.replica_server_name AS ag_replica_server, dr_state.database_id AS database_id, is_ag_replica_local = CASE WHEN ar_state.is_local = 1 THEN N'LOCAL' ELSE 'REMOTE' END, ag_replica_role = CASE WHEN ar_state.role_desc IS NULL THEN N'DISCONNECTED' ELSE ar_state.role_desc END, dr_state.last_hardened_lsn, dr_state.last_hardened_time, datediff(s,last_hardened_time, getdate()) AS 'seconds behind primary' FROM (( sys.availability_groups AS ag JOIN sys.availability_replicas AS ar ON ag.group_id = ar.group_id) JOIN sys.dm_hadr_availability_replica_states AS ar_state ON ar.replica_id = ar_state.replica_id) JOIN sys.dm_hadr_database_replica_states dr_state ON ag.group_id = dr_state.group_id AND dr_state.replica_id = ar_state.replica_id
如果数据库的状态不是同步的,如何收到警报?
可以使用以下脚本:
SELECT ag.name AS ag_name, ar.replica_server_name AS ag_replica_server, dr_state.database_id AS database_id, is_ag_replica_local = CASE WHEN ar_state.is_local = 1 THEN N'LOCAL' ELSE 'REMOTE' END, ag_replica_role = CASE WHEN ar_state.role_desc IS NULL THEN N'DISCONNECTED' ELSE ar_state.role_desc END, ar_state.connected_state_desc, ar.availability_mode_desc, dr_state.synchronization_state_desc FROM (( sys.availability_groups AS ag JOIN sys.availability_replicas AS ar ON ag.group_id = ar.group_id ) JOIN sys.dm_hadr_availability_replica_states AS ar_state ON ar.replica_id = ar_state.replica_id) JOIN sys.dm_hadr_database_replica_states dr_state ON ag.group_id = dr_state.group_id AND dr_state.replica_id = ar_state.replica_id
还可以查看以下链接,了解监视Always On组的其他方法: