我们最近更改了镜像设置以包含见证人，以便我们支持自动故障转移，昨天在我们的数据中心，他们对一些网络供应进行了一些计划维护（我相信他们更改了一些路由器和东西）。
遗憾的是，这导致我们的网络出现一些不稳定，现在我无法改变任何事情（除了写一封愤怒的电子邮件！）。真正让我困扰的是以下情况。
我们在称为 90 的主体上运行着大约 10 个数据库，91 是我们的镜像，92 作为我们的见证运行。
昨天 09:35，见证者和镜像声称与主体失去联系，并将镜像提升为主体。然而，主体（在 90 上）从未声称与见证者失去联系，而是继续工作（保持在线）。然后在 09:54 左右，90 声称与镜像失去联系（这很合理，因为在 09:25 这成为了主体……它只是晚了 30 分钟才意识到这一点？！）。
此时我们有两个 quarum。90 可以看到 92 并且仍然是主要成员，而已晋升的 91 也可以看到 92...
遗憾的是，此时主体（90）开始出现一些可怕的死锁并拒绝响应任何命令，但是，具有与故障转移伙伴设置的连接字符串的客户端仍然可以 ping/连接到 90，这意味着它们都无法故障转移到 91。最后，我们重新启动了 90 上的 SQL Server 实例，这使得所有数据库都可以正确进行故障转移。
我个人不知道这种情况是如何发生的，如果我们的设置有问题，那么我们不知何故有两个主体这一事实确实让我很困扰，特别是因为原始主体启动并运行了大约 30 分钟，而当我们设法将其变成镜像时，留下了 30 分钟的间隙。
由于目前我们对这一切感到非常震惊，因此任何有关此事的信息都将不胜感激。
答案1
当时（09:35），您是否检查了镜像监视器以查看其状态？您是否收到这些事件的通知？
有可能由于网络维护，90 和 91/92 之间的连接断开了，所以 91 也成为了主要连接，对于客户端来说什么也不会发生，因为与 90 的连接仍然畅通，从而造成了你的情况。
如果我意识到这两个主要情况，我可能会做什么（现在说起来容易：）......
在当时运行良好的 90 上，为客户端等提供服务，从数据库中删除镜像配置，这样数据库就保持一致并且一切都保持在线。
之后，您可以重新配置镜像，无需任何停机时间。