Mik*_*ike 7 sql-server sql-server-2012 availability-groups
我们有一个在 Windows Server 2012 R2 上运行 SQL Server 2012 的双节点集群设置。基础集群仅由这两个节点组成。仲裁设置为节点 + 磁盘多数，共享磁盘位于通过 iSCSI 连接的 EqualLogic 阵列上。集群配置验证没有错误。
今天早些时候，集群上运行的两个可用性组（节点 #1 上的主节点）在两个节点上都进入了解决状态。查看集群事件，在它尝试重新启动服务之前什么也没有。Windows 故障转移群集下的所有内容都显示为绿色（在线且无警告） - 磁盘、网络接口、节点等。
查看 Windows 事件查看器中的应用程序日志，由于无法建立仲裁，群集已请求显示可用性组正在进入解决状态的事件。我在任何日志中找不到任何其他内容来支持这一点，并且在集群验证期间仲裁通过。
AG 不会恢复。我们在 SQL Server 日志中的 AlwaysOn 日志中发现，第一个节点出现了镜像端点故障。这在内存访问冲突后立即发生，其症状类似于 Microsoft 已通过累积更新 6 解决的问题，因此我们将在接下来尝试。
我能够重新启动节点 1 上的 SQL Server 服务（第二个注释无法与之通信的内存访问冲突），并且我能够在那时使可用性组重新联机。重新启动也会使一切恢复到 100%。
您是否有任何见解，为什么当镜像端点失败时，节点 1 不会发生故障并让数据库在节点 2 上保持活动状态？我们目前处于 AG 3 级；将其提高到 4 会触发节点 1 上的故障，同时让节点 2 上的服务保持活动状态吗？
小智 0
我的一个可用性组有相同的症状。由于维护原因，1 个节点已关闭。仲裁仍然来自第二个节点和文件共享。
7 小时后，活动节点（可能）失去了与文件共享的连接，并且最后一个站着的节点已停止为客户端提供服务 - 已失去与法定人数主要部分的连接。
当文件共享变得可用时，它尚未从“正在解析”状态中恢复，只有 SQL Server 服务重新启动才有帮助。可能是由于不确定数据在纸牌期间是否没有被修改。
| 归档时间： |
|
| 查看次数： |
18934 次 |
| 最近记录： |