跳到主要内容

在站点间切换服务概述

要在复制组内从一个站点切换复制服务（即，进行故障转移）到另一个站点，必须进行两个活动：

  • 必须手动更改事件代理上复制服务的状态（活动或备用）。
  • 客户端必须连接到新的活动站点（这可以配置为自动发生）。

更改复制状态​

在活动复制站点发生故障时，网络运营商可以将备用复制站点上事件代理的消息 VPN 的复制状态从备用更改为活动。然后，消息客户端可以重新连接到新活动复制站点上同名的消息 VPN，并且可以继续处理保证消息和事务。

在高流量率或不幸的故障转移时机下，有小的可能性在故障转移后可能会出现消息重复。建议无法容忍在任何情况下重复消息传递的应用程序应实现应用层机制（例如，全局唯一消息 ID）以检测重复消息传递。或者，如果应用程序维护了它已处理的复制组消息 ID 的历史记录，可以比较接收到的消息的复制组消息 ID 与已处理的消息的复制组消息 ID。

在使用事务（本地和 XA）时，活动站点上的并非所有事务状态都会在复制备用站点上镜像。只有那些在故障转移时保持事务行为所必需的状态才会被保留。例如，处于 ACTIVE 状态的 XA 事务不会被镜像。在复制故障转移的情况下，应用程序服务器事务管理器预计会检测到这一点并妥善处理。

更多信息，请参阅检测重复消息。

有关执行复制故障转移的说明，请参阅在站点间切换复制服务的程序。

客户端重新连接​

要自动将消息客户端连接到新的活动复制站点，您可以使用 Solace 消息 API 的主机列表功能。主机列表提供了两个复制站点中事件代理的 IP 地址或主机名。通常，主机列表包含主站点，后跟备份站点。当其与主站点的连接断开或更改为备用状态时，客户端会自动尝试连接到备份站点，即主机列表中的下一个主机。

当具有活动复制状态的消息 VPN 切换到复制备用时，所有活动客户端都会被断开连接。

复制故障转移类型​

有四种类型的复制故障转移：

  • 控制性故障转移
  • 非控制性故障转移，短期中断
  • 非控制性故障转移，长期中断
  • 非控制性故障转移，完全失败

控制性故障转移​

这是一个由管理员根据文档程序触发的故障转移。在这种情况下，两个站点都在服务中，并且可以相互通信。

非控制性故障转移，短期中断​

在这种故障转移类型中，活动站点或与客户端和备用站点隔离的状态持续很短的时间（分钟，小时）。在这种情况下，可以使备用站点变为活动站点，并且复制队列（#MSGVPN_REPLICATION_DATA_QUEUE）有足够的容量来存储所有复制的消息和事务（使用异步复制），直到恢复服务或与失败站点的连接。恢复的站点成为备用站点，清空复制队列（#MSGVPN_REPLICATION_DATA_QUEUE）来自活动站点，并且完全恢复复制行为。

非控制性故障转移，长期中断​

在这种故障转移类型中，活动站点或与备用站点隔离的状态持续很长时间（天，周）。在这种情况下，可以使备用站点变为活动站点，但复制队列（#MSGVPN_REPLICATION_DATA_QUEUE）可能会满。当复制队列满时，可以在复制队列上禁用 reject-msg-to-sender-on-discard 以在新活动站点上提供非复制服务。一旦失败的站点恢复，恢复的站点成为备用站点，并从活动站点清空复制队列。没有进入复制队列的消息和事务将不会被复制。

非控制性故障转移，完全失败​

在这种故障转移类型中，活动站点无法提供服务且无法恢复（例如，整个事件代理已被新的替换）。在这种情况下，备用站点可以在等待替换的同时变为活动站点，复制的消息和事务存储在复制队列中。根据获取替换所需的时间，将适用短期或长期中断行为。

恢复到原始活动站点​

在故障转移后，一旦失败的站点恢复，可能希望恢复到原始活动站点。这在备份站点的容量较低或故障保护较少于主站点时尤其如此。在控制性故障转移后恢复没有特殊考虑。然而，在非控制性故障转移后，存在消息丢失或重复的风险，这根据场景略有不同：

  • 非控制性故障转移，短期中断 - 在恢复过程中，当故障转移发生时正在进行的复制消息或事务，并且尚未被消费，存在丢失或重复的风险。
  • 非控制性故障转移，长期中断 - 在恢复过程中，当故障转移发生时正在进行的复制消息或事务，并且尚未被消费，存在丢失或重复的风险。此外，只有那些进入复制队列的消息和事务将可用。
  • 非控制性故障转移，完全失败 - 根据替换失败复制站点所需的时间，将适用短期或长期失败的考虑。此外，替换的事件代理将没有历史数据，因此在故障转移之前尚未被消费的复制消息将丢失。

在所有恢复到原始活动站点的情况下，如果所有在故障转移之前发布并且在故障转移期间正在进行的复制消息都已在新活动站点上被消费，可以消除消息丢失或重复的风险。换句话说，如果让备份复制站点保持活动状态足够长的时间，以确保所有在故障转移之前发布的消息都已被消费，将不会有消息丢失。