第五十六章 镜像中断程序 - 计划外停机程序
计划外停机程序
当一个故障转移成员意外失败时，适当的程序取决于哪个 实例失败，镜像所处的故障转移模式（参见自动故障转移机制详述），另一个故障转移成员实例的状态，两个故障转移成员的 ISCAgent 的可用性, 和镜像的设置。
- 备份故障转移成员的计划外中断
- 具有自动故障转移的主要故障转移成员的计划外中断
- 未发生自动故障转移时主要故障转移成员的计划外中断
- 主要故障转移成员的计划外隔离
- 两个故障转移成员的计划外中断
在阅读和使用本节时，您能需要查看对各种中断情况的镜像响应，其中讨论了主服务器变得不可用时备份行为的详细信息。
备份故障转移成员的计划外中断
当备份故障转移成员的 实例或其主机系统发生故障时，主要继续正常运行，尽管某些应用程序可能会出现短暂的暂停（有关详细信息，请参阅备份中断的影响）。
当备份发生意外中断时，纠正导致故障的条件，然后重新启动备份实例或主机系统。当备份的 实例重新启动时，它会自动加入镜像作为备份。
注意：如果备份在代理控制模式下失败（请参阅自动故障转移规则）并且无法联系到备份的 ISCAgent，则主的 实例在重新启动后无法成为主实例，因为它无法确定它是否是最近的主实例.因此，如果出于任何原因需要在备份主机系统关闭时重新启动实例，则必须使用维护备份故障转移成员中描述的过程来执行此操作。
具有自动故障转移的主要故障转移成员的计划外中断
如自动故障转移规则中所述，当主要 实例不可用时，备份可以自动接管主要实例
- 备份处于活动状态并且
- 从请求它接管的主要接收通信。
- 从仲裁器接收到它也已与主节点失去联系的信息。
- 如果仲裁器不可用或未配置仲裁器，则联系主实例的
ISCAgent以确认主实例已关闭或挂起。
- 备份不活动，但可以联系主实例的
ISCAgent以确认主实例已关闭或挂起，并从ISCAgent获取主实例的最新日志数据。
当备份在计划外的主要中断后自动接管时，纠正导致中断的条件，然后重新启动以前的主要 实例或主机系统。当 实例重新启动时，它会自动加入镜像作为备份。如果想将以前的主要成员恢复到原来的角色，请在备份 实例上正常关闭以触发故障转移，然后重新启动它，如主要故障转移成员的维护中所述。
未发生自动故障转移时主要故障转移成员的计划外中断
如自动故障转移规则中所述，当主要主机系统（包括其 ISCAgent）不可用且满足以下任何条件时，备用 实例无法自动接管无响应的主要实例：
- 备份未激活。
- 备份因错误而无法接管。
- 备份无法验证主服务器是否已关闭，因为没有配置仲裁器，或者因为它在与主
IRIS实例及其ISCAgent失去联系之前或同时与仲裁器失去联系。
在这种情况下，有三种可能的情况，下面列出了每种情况以及可能的解决方案：
- 主要主机系统出现故障但可以重新启动。可以执行以下任一操作：
- 重启主主机系统而不重启主
IRIS实例。当主要的ISCAgent可用时，备份会在必要时从中获取最新的日志数据并成为主要的。 - 重新启动主要主机系统，包括主要 实例。故障转移成员协商，直到一个成为主要成员，另一个成为备份成员。
- 主要主机系统出现故障且无法重新启动。可以手动强制备份接管。这个过程取决于备份在失去与主服务器的连接时是否处于活动状态；如以下各节所述，存在数据丢失的风险。
- 主主机系统正在运行，但与仲裁器和备份器网络隔离；有关过程，请参阅主要故障转移成员的计划外隔离。
手动强制故障转移成员成为主要成员
当故障转移成员无法成为主要成员时，可以强制它这样做，但如果在最后一个主要成员可能拥有比强制的成员更新的日志数据的任何情况下这样做，则存在数据丢失的风险。以下过程描述了如何确定和管理该风险。如果在无法确认某个成员具有最新的日志数据时强制使其成为主要成员，则其他镜像成员可能无法重新加入镜像，因此需要重建（如重建镜像成员中所述）。
小心：在继续之前，请确认主节点已关闭并将在此过程中保持关闭状态。如果您无法确认，最好中止此过程，以避免原始主节点再次可用的风险，导致两个成员同时充当主节点。
网友评论