第五十八章镜像中断程序 - 主要故障转移成员的计划外隔离

主要故障转移成员的计划外隔离

如自动故障转移机制中所述，当主节点同时与备份节点和仲裁节点失去联系时，它会进入无限期的故障状态并且不能再作为主节点运行。通常，发生这种情况时，备份会接管并成为主要的。当主服务器与备份服务器的连接恢复时，备份服务器强制关闭主服务器；或者，可以在恢复连接之前自行强制关闭主服务器。

但是，如果一个网络事件（或一系列网络事件）导致故障转移成员和仲裁器同时（或几乎同时）彼此失去联系，则可能没有主节点，因为备份无法接管并且主节点不再存在作为主要操作。这种情况显示为自动故障转移机制详细部分中仲裁模式下对丢失连接的镜像响应表中的最终方案。当主数据库变得孤立并且备份由于错误而无法接管时，可能会发生类似的情况。

当这些情况发生时，有以下选择：

恢复故障转移成员之间的连接；当前一个备份与前一个主要联系时，成员进行协商，一个成为主要，另一个成为备份。
在不恢复连接的情况下，如果可以在主服务器上打开终端窗口，请这样做并在主服务器上运行 ^MIRROR 例程（请参阅使用 ^MIRROR 例程）。该例程确认主实例处于不确定的故障状态，并为您提供两个选项：
- 如果确认另一个故障转移成员已关闭（可能是因为您将其关闭），它从未成为主成员，并且它没有创建比主成员上的最新镜像日志文件晚的镜像日志文件，可以强制该成员恢复操作为主。一旦它这样做了，并且你恢复了主备之间的连接，备份恢复操作作为备份。
- 如果无法确认这些条件，则可以关闭主节点。然后，可以使用在未发生自动故障转移时主故障转移成员的计划外中断中描述的过程之一手动故障转移到备份。
如果无法在主服务器上打开终端窗口，但可以确认另一个故障转移成员已关闭，它从未成为主服务器，并且它没有在主服务器上创建比最新文件晚的镜像日志文件，可以重新启动主要的 IRIS 实例，并使用强制此节点成为主要的 ^MIRROR 例程的选项强制它成为主要的。或者，如果无法确认这些情况，可以确保主 IRIS 实例已关闭并将保持关闭状态，然后使用自动故障转移未发生时主故障转移成员的计划外中断中描述的过程之一手动故障转移到备份发生。

小心：如果在未确认列出的条件的情况下强制主节点作为主节点恢复操作，将面临数据丢失或两个故障转移成员同时充当主节点的风险。

两个故障转移成员的计划外中断

当两个故障转移成员由于同一事件或不同事件而意外失败时，适当的过程取决于您是否可以在可用性要求的限制内重新启动其中一个或两个故障转移成员。镜像停止运行的时间越长，可能拥有的选择就越多。

如果可以重新启动两个代理和至少一个 IRIS 实例，则故障转移成员将相互协商并自动选择其中的一个作为主要代理，使镜像恢复运行而没有数据丢失的风险。
如果确定知道哪个故障转移成员是最后一个主要成员并且可以重新启动它，如果它无法与其他故障转移成员的 IRIS 实例或代理（因为它们已关闭）通信，它不会自动成为主要成员，但可以使用 Force this node to become the primary option of the ^MIRROR routine (as Unplanned Outage of Primary Failover Member Without Automatic Failover) 中所述，手动强制它成为主节点，没有数据丢失的风险。
如果只能重新启动其中一个故障转移成员但不知道它是否是最后一个主节点，则可以使用强制此节点成为 ^MIRROR 例程的主选项来手动强制它成为主节点，但有一些数据风险损失。

小心：如果强制一个不活动的备份成为主要备份，一些全局更新操作可能会丢失，并且其他镜像成员可能需要重建（如重建镜像成员中所述）。

如果无法重新启动任何一个故障转移成员，请继续执行灾难恢复过程。