介绍

     物理故障、操作系统故障或 SQL Server 故障都可能导致两个可用性副本之间的会话失败。 可用性副本不会定期检查 Sqlservr.exe 所依赖的组件来验证这些组件是在正常运行还是已出现故障。 但对于某些类型的故障，受影响的组件将向 Sqlservr.exe 报告错误。 由另一个组件报告的错误称为“硬错误 ”。 为了检测可能忽略的其他故障，Always On 可用性组实施了自己的会话超时机制。 以秒为单位指定会话超时期限。 此超时期限是一个服务器实例在考虑断开另一实例的连接之前，等待接收来自该实例的 PING 消息的最长时间。 两个可用性副本之间发生会话超时时，可用性副本将假定已发生故障并声明一个“软错误”。

硬错误导致的故障

 可能的硬错误原因包括（但不限于）下列几种情况：

• 连接或网线断开
• 网卡出现故障
• 路由器更改
• 防火墙更改
• 端点重新配置
• 事务日志驻留的驱动器丢失
• 操作系统或进程故障

例如，如果主数据库中的日志驱动器停止响应或失败，操作系统会通知 Sqlservr.exe 出现严重错误。

某些组件（如网络组件和某些 IO 子系统）使用它们自己的超时设置来确定故障。 这些超时设置独立于 Always On 可用性组，后者不了解它们，并且完全不能识别其行为。 在这些情况下，超时延迟会延长发生故障与可用性副本收到所引发硬错误之间的时间。

软错误导致的故障

 可能导致会话超时的情况包括（但不限于）下列各项：

• 诸如 TCP 链接超时、数据包被删除或损坏或数据包顺序错误等网络错误。
• 操作系统、服务器或数据库处于挂起状态。
• Windows 服务器超时。
• 计算资源不足，例如 CPU 或磁盘超负荷运转，事务日志填满，或系统用完内存或线程。 在这些情况下，需要增加超时期限、降低工作负荷或更换硬件以处理相应的工作负荷。

回话超时机制

      由于软错误不能由服务器实例直接检测到，因此，软错误可能导致一个可用性副本无限期等待会话中另一个可用性副本的响应。 为了防止发生这种情况， Always On 可用性组实施了会话超时机制，此机制基于以下条件：所连接的可用性副本会在每个打开的连接上按固定间隔发送 ping。 在超时期限内收到 ping 指示连接仍是开放的且服务器实例正在通过此连接进行通信。 收到 ping后副本将重置此连接上的超时计数器。主副本和辅助副本相互 ping 以指示它们仍处于活动状态， 会话超时限制是用户可配置的副本属性，默认值为 10 秒。

如果在会话超时期限内没有收到来自另一个副本的ping，该连接将超时、连接将关闭；超时的副本进入 DISCONNECTED 状态。 即使为同步提交模式的副本，事务也将不等待该副本重新连接暂时将该辅助副本切换到异步提交模式。在该辅助副本重新与主副本连接后，它们将恢复同步提交模式。

参考：https://msdn.microsoft.com/zh-cn/library/ff877884(v=sql.120).aspx

总结

无法检测到主数据库之外的数据库中的故障。 此外，也不太可能检测到数据磁盘故障，除非数据库因为数据磁盘故障而重新启动，仅在出现软错误时，才对可用性副本执行有效的错误检查。