现在最流行的网站推广方式有哪些1688官网
文章目录
- 第九章 镜像架构和规划 - 备份处于活动状态时自动进行故障转移
- 备份处于活动状态时自动进行故障转移
- 备份不活动时的自动故障转移
- 对各种中断场景的镜像响应
- 响应主要中断场景的自动故障转移
第九章 镜像架构和规划 - 备份处于活动状态时自动进行故障转移
备份处于活动状态时自动进行故障转移
当备份处于活动状态时，如果它可以确认故障转移的第二个条件——即主服务器未作为主服务器运行并且在没有人为干预的情况下无法继续运行，则它有资格作为主服务器接管。备份可以通过以下三种方式之一执行此操作：
- 通过接收来自主要请求它接管的通信。
这发生在主实例正常关闭期间或当主实例检测到它已挂起时。一旦主要发送此消息，它就不能再充当主要并且活动备份可以安全地接管。如果前一个主节点挂起，新的主节点会迫使它关闭。
- 通过从仲裁器接收到它已与主节点失去联系的信息。
主要和备用 IRIS 实例与仲裁器保持持续联系，仲裁器会在与其他故障转移成员的联系中断或恢复时更新每个实例。当一个网络事件同时将主节点与备份节点和仲裁节点隔离开来时，它就会无限期地进入故障状态。因此，如果一个活动的备份失去了与主的联系，并从仲裁器得知它也失去了与主的联系，备份可以安全地接管，因为主必须要么已经失败，要么被隔离并处于故障状态，因此不能再充当主要角色。恢复连接时，如果以前的主节点挂起，新的主节点会强制关闭它。
- 通过从主系统的
ISCAgent接收主实例已关闭或挂起的信息。
当仲裁器不可用或未配置仲裁器时，与主实例失去联系的活动备份可以尝试联系主实例的 ISCAgent（这只有在主实例的主机系统仍在运行时才有可能）以确认主实例是下来，或者如果它被挂起就强迫它下来。一旦代理确认主服务器不能再充当主服务器并且因此故障转移是安全的，备份就会接管。
当主数据库因网络事件与活动备份隔离，但备份无法通过其中一种方式确认安全故障转移条件时，备份不再处于活动状态，并受下一节中描述的故障转移机制的约束。
备份不活动时的自动故障转移
不活动的备份可以尝试联系主实例的 ISCAgent 以确认主实例已关闭或在挂起时强制其关闭，并从代理获取主实例的最新日志数据。如果在这两个方面都成功，备份可以安全地接管为主。
不活动且无法联系主服务器的 ISCAgent 的备份无法确保主服务器不再充当主服务器并且它具有来自主服务器的最新日志更新，因此无法接管。
当备份不活动时，仲裁器在故障转移机制中不起作用。
对各种中断场景的镜像响应
本节总结了镜像对不同组合的故障转移成员和仲裁器中断的响应。
注意：操作员可以暂时关闭主系统而不会导致发生故障转移。这可能很有用，例如，如果主系统需要在很短的时间内关闭以进行维护。备份主系统后，将恢复自动故障转移的默认行为。
这里讨论的几个场景涉及手动强制备份成为主要的选项。有关此过程的信息，请参阅没有自动故障转移的主要故障转移成员的计划外中断。
响应主要中断场景的自动故障转移
虽然情况和细节各不相同，但有几种主要的主要中断情况，在这些情况下，活动备份故障转移成员会自动接管，如下所示：
- 主要的计划中断（例如出于维护目的）是通过关闭其
IRIS实例来启动的。
发生自动故障转移是因为主服务器指示活动备份接管。
- 由于意外情况，主
IRIS实例挂起。
发生自动故障转移是因为主要检测到它已挂起并指示活动备份接管。
- 由于意外情况，主
IRIS实例被迫关闭或变得完全无响应。
在这种情况下，主服务器无法指示备份接管。但是，主动备份在从仲裁器得知它也与主服务器失去联系后或通过联系主服务器的 ISCAgent 并获得主服务器已关闭的确认后接管。
- 主存储子系统发生故障。
存储故障的典型后果是主实例由于 I/O 错误而挂起，在这种情况下，主实例检测到它已挂起并指示活动备份接管（如场景 2）。但是，在某些情况下，场景 3 或场景 5 中描述的行为可能适用。
- 主要主机系统出现故障或变得无响应。
如果活动备份从仲裁器得知它也已与主备份失去联系，则会发生自动故障转移。
如果没有配置仲裁器，或者如果仲裁器在主要主机故障之前变得不可用，则无法进行自动故障转移；在这些情况下，手动强制备份成为主要可能是一种选择。
- 网络问题隔离了主要。
如果配置了仲裁器并且两个故障转移成员在网络故障时都连接到仲裁器，则主节点无限期地进入故障状态。
- 如果活动备份从仲裁器获悉它也已与主服务器失去联系，则会发生自动故障转移。
- 如果备份在与主服务器失去联系的同时与仲裁器失去联系，则无法进行自动故障转移。如果两个故障转移成员都已启动，则当网络恢复时，备份会联系主要成员，然后恢复作为主要成员的操作。或者，可以手动指定主要对象。
如果没有配置仲裁器或其中一个故障转移成员在网络故障之前与其断开连接，则自动故障转移是不可能的，并且主节点继续作为主节点运行。
不活动的备份（因为它正在启动或落后）可以通过联系主服务器的 ISCAgent 并获取最新的日志数据来接管上述第 1 到 4 种情况。在场景 5 和 6 下，不活动的备份无法接管，因为它无法联系 ISCAgent；在这些情况下;手动强制备份成为主要可能是一种选择。