Freigeben über

运行 Windows Server 2008 R2 的数据库可用性组的建议的 Windows 修补程序

  • Artikel

原文发布于 2011 年 11 月 20 日（星期日）

今年八月初，Windows SE 团队发布了以下知识库 (KB) 文章，并附带了与 Windows Server 2008 R2 故障转移群集中存在的问题相关的软件修补程序：

KB2550886 - 暂时的通信失败导致 Windows Server 2008 R2 故障转移群集停止工作（该链接可能指向英文页面）

强烈建议对跨多个数据中心拉伸的所有数据库可用性组使用此修补程序。对未跨多个数据中心拉伸的数据库可用性组使用此修补程序也很有效。本文介绍了当 Windows 故障转移群集遇到暂时的通信失败时，会出现的争用条件和群集数据库死锁问题。当群集出现通信失败时，显现的群集节点的重新连接逻辑中存在争用条件。发生此情况时，它将导致群集数据库挂起，从而导致故障转移群集中丢失仲裁。

如 TechNet 上所述，数据库可用性组 (DAG) 依赖于特定的群集功能，包括群集数据库。为了使 DAG 能够正常运行并提供高可用性，群集和群集数据库也必须正常运行。

Microsoft 遇到了以下情况：发生了暂时的网络失败（网络通信失败的持续时间约为 60 秒），从而导致整个群集处于死锁状态，并且 DAG 中的所有数据库被卸除。由于确定实际处于死锁状态的群集节点并不是件很轻松的工作，因此，如果故障转移群集死锁是因重新连接逻辑争用导致的，则唯一可用操作是重新启动整个群集中的所有成员以解析死锁条件。

通常，以群集仲裁丢失形式显现的问题是因非对称通信失败（当两个节点无法相互通信但仍可与其他节点通信时）导致的。如果其他节点在接收来自群集的全局更新管理器 (GUM) 的群集重组消息时出现延迟，则可按意外的顺序接收重组消息。出现此情况时，群集将丢失仲裁，而不是调用预期行为，这会从群集中删除遇到初始通信失败的某个节点。

通常，当发现各个对之间的断开连接的两个群集节点中存在非对称延迟时（例如，一半 DAG 成员具有 1 ms 的延迟，另一半 DAG 成员具有 30 ms 的延迟），将出现此 Bug。如果第一个节点在第二个节点之前检测到连接丢失，则会出现争用情况：

  • 第一个节点将在两个节点之间开始重新连接流。这将导致第二个节点向其数据添加新流。
  • 添加新流会毁坏旧流，并会将其失败处理程序设置为忽略。在发生失败的情况下，旧流是指尚未检测的失败流。
  • 当在第二个节点上检测到连接中断时，第二个节点将启动自己的重新连接序列。如果在适当的争用窗口中检测到连接中断，则会将失败流的失败处理程序设置为忽略，并且重新连接过程不会启动重新连接。不过，它将为发送队列发出暂停指令，这将停止在节点之间发送消息。当停止消息时，将阻止 GUM 正常运行并会强制重新启动群集。

如果出现此问题，则获得的结果会对 DAG 产生很不利的影响。因此，我们建议您将此修补程序部署到作为 DAG 成员的所有邮箱服务器，尤其是当跨数据中心拉伸 DAG 时。另外，此修补程序对运行 Exchange 2007 单一副本群集的环境和群集连续复制环境很有用。

除了解决上述问题之外，KB2550886 还包括其他重要的 Windows Server 2008 R2 修补程序，建议对 DAG 使用这些修补程序：

这是一篇本地化的博客文章。请访问 Recommended Windows Hotfix for Database Availability Groups running Windows Server 2008 R2 以查看原文