假设我在 4 节点集群中有 AG，主站点上有 2 个节点，灾难恢复站点上有 2 个节点，1 个云见证。故障转移模式是手动的。
现在由于某种原因，假设主站点网络出现故障，特别是我无法连接到主数据中心。
情况 1：主节点具有法定人数，因为它仍然能够与云见证进行通信。由于主站点存在一些网络问题，SQL 仍在主站点上运行，并认为它是主站点。
情况 2：主节点无法与云见证通信并且已失去法定人数。动态见证人和动态法定人数可能会生效。
假设我现在连接到其中一个 DR 节点并调用强制手动故障转移。
当我调用手动故障转移时，DR 站点上的 SQL 会认为它是主站点。从技术上讲，这是一个拆分集群场景。
案例 1 中的分裂场景是显而易见的。在情况 2 中，这可能是由于动态见证人和动态法定人数的启动所致。
当主要网络重新建立时，我需要做什么来处理这种情况？因为如果我的想法是正确的，那么两个站点都会认为它拥有主 SQL 服务器。
你自己就是故意脑裂的。由于 DR 端没有仲裁，因此需要强制，这意味着当这些节点再次相互通信时，原始主端将看到强制仲裁，并且主端将立即关闭并重新启动以与来自 DR 端的新集群数据库是强制的。这将产生使初级侧的 AG 瘫痪的效果。问题是，现在您有可能（尽管这几乎是保证）原始主节点具有 DR 端由于您强制的脑裂而没有的数据。
这意味着您需要手动协调数据并将其从原始主数据库放入灾难恢复数据库中。没有人可以告诉您所需的操作，因为它特定于您的数据库和公司。
一旦数据被协调（或决定不协调），副本很可能需要重新初始化，因为恢复分叉相距太远，并且最后一个公共分叉将来自问题发生的日期和时间。由于使用了强制故障转移，数据库需要恢复数据移动或完全删除数据才能自动播种（或者您可以手动播种）。您将无法神奇地记录恢复或此处的任何内容，因为数据库已在其恢复路径中分叉。
初选方不会获得选票，也不会坚持下去。如果 DR 方能够接触到见证人，那么它应该获得选票并且达到法定人数。如果为 DR 位置中的一个副本设置了自动故障转移，那么这应该自动进行故障转移，如果没有，则需要正常故障转移（如果它是同步提交伙伴）或强制故障转移（异步提交伙伴）。然后，您需要在 DR 端仍处于活动状态的每个副本上恢复数据移动。根据它们失去通信的时间，您可能需要删除原始主端上的副本。
一旦 AG 被强制转移，当通信返回时，AG 将查看它是否被强制转移。如果有，则假设副本未删除，所有通信都将与原始主端上每个副本上的数据库进行。如果是，您需要将它们添加回 AG。