场景 HASL1.3：主服务器失败，随后见证服务器失败

主服务器失败后发生故障转移。见证服务器可能接下来也失败，如图4所示：

图4：见证服务器紧随原始主服务器出现失败，那么新主服务器无法提供数据库服务

当见证服务器 Server W主服务器 Server A失败后也出现失败，那么新主服务器 Server B依然为主服务器但被孤立，无法组成quorum，也不能提供数据库服务。

如果Server A首先恢复，Server B的mirroring_role_sequence号将比Server A的大1，因为产生了故障转移。这些信息指示Server A如今Server B在Server A只有担当了主服务器的角色。Server A和Server B组成quorum 并成为一对镜像，此后两台服务器保持同步。除非Server W恢复，否则不会产生自动故障转移。

注意： 如果Server W在Server A和Server B相继之后也宣告失败，那么无论以什么次序恢复见证服务器，已经转换完成的Server A和Server B的角色将保持不变。

场景 HASL2.1：镜像服务器失败

如果镜像服务器首先失败，那么主服务器被视为exposed，因为它无法发送数据给镜像服务器。图 5显示了Server B，即镜像服务器失败时的行为。

图5：在高可用模式下，当镜像服务器Server B失败时不产生故障转移

没有自动故障转移发生，镜像伙伴也不会交换角色。当Server B恢复时，所有三台服务器还原到其初始角色和状态。

下表显示了镜像服务器Server B失败以及恢复时数据库状态。

由于没有镜像服务器，数据无法存放在冗余数据库中，因此会话处于exposed。

Server B一旦恢复立刻重新担当起它的镜像服务器角色。只要两台服务器同步，镜像会话就不再被视为exposed。

接下来的两个场景考虑镜像服务器Server B失败，紧接着主服务器Server A或者见证服务器Server W失败时产生的结果。

场景 HASL2.2：镜像服务器失败，随后主服务器失败

紧随镜像服务器之后主服务器也失败了，镜像伙伴服务器的角色保持不变。图6显示了采用不同方式还原服务器时角色将如何转换。

图6：镜像服务器失败随后主服务器主失败，那么见证服务器被孤立

在Server B和Server A都失败后，各服务器状态显示在图中的右上角处。

如果Server B首先恢复，它将从见证服务器Server W处检测到Server A依然为主服务器并且还没有产生故障转移，mirroring_failover_lsn也没有增加。其结果为，Server B依然为镜像服务器。Server W恢复后将会话还原到初始状态。

注意：如果Server W在Server B和Server A相继失败之后也宣告失败了，那么以任何顺序还原这些服务器将导致相同结果。