1

通常，我们有两种方法来恢复 QMGR。一个是backup and restore QMGR data&log，另一个是create backup QMGR。我的问题是哪一个更适合 QMGR 恢复情况？还是他们都有自己的使用场景？请帮忙回答这个问题。

谢谢

4

1 回答 1

1

究竟从什么恢复？有什么恢复时间目标或什么恢复点目标？ 最佳答案取决于这些要求以及您的应用程序的编写方式。从架构的角度来看，最好的方法是将消息传递视为传输。当您备份您的网络路由器时，您不会备份恰好在路由器上传输的消息，您只需备份路由器配置。队列管理器也是如此。如果您备份对象定义、授权、ini 文件、退出和退出参数，您可以重新创建 QMgr 的空版本并从旧版本停止的地方继续。

不幸的是，大多数应用程序被设计为好像消息传递层是一个数据库而不是一个传输层。这意味着他们希望从停机的 QMgr 中恢复消息。这就是Backup QMgr的用途。它的工作方式是主 QMgr 使用线性日志文件。随着时间的推移，活动日志文件会前进，而不再需要恢复的旧文件会“滚动”到日志集的末尾。然后将这些文件传送到备份 QMgr 所在的位置并应用。然后，备份 QMgr 将拥有该日志文件上次活动时队列中消息的精确副本。

主队列管理器上的消息与备份队列管理器上的消息之间总是存在滞后，滞后由主要和辅助活动日志扩展区​​占用的空间表示。如果主日志盘区和辅助日志盘区的大小和数量保持较小，则可以最大限度地减少故障转移中丢失的消息数量。这种方式无法实现零恢复点，但它比时间点备份好很多。

这将我们引向您提到的其他备份方法。如果在 QMgr 运行时进行备份，则时间点备份（即备份 QMgr 的队列和日志文件）将无法工作。在繁忙的 QMgr 上，日志和队列不断被写入并且必须保持同步。但是在活动时备份这些文件几乎可以保证备份的日志不会与备份的队列同步。QMgr 可能会在队列损坏的情况下恢复，或者 QMgr 在恢复后甚至不会启动。

此备份策略唯一有效的情况是如果 QMgr 已停止，那么它最好用于升级后的恢复选项，而不是用于活动系统。例如，假设您在周日早上 1 点进行了有效的时间点备份。然后在一周内，有人从 QMgr 下删除了一个队列文件，您需要恢复它。恢复 onbe 文件将不起作用，因为它将与日志不同步并显示为损坏的对象。您必须恢复整个 QMgr。您得到的是截至上周日凌晨 1 点在所有队列中的所有消息。更糟糕的是，如果 QMgr 参与集群，将其恢复到之前的时间点会重置集群命令消息上的序列号，因此即使看起来就像 QMgr 已恢复并且健康一样，集群可能会忽略它或您对其所做的任何更改。

最常见但在您的帖子中未提及的一种备份策略是备份 QMgr 配置。这包括：

  • 对象定义
  • 授权
  • 退出目录
  • 退出参数
  • ini 文件

通过这些，您将能够重新创建队列管理器配置，并且所有这些备份都可以在 QMgr 运行时完成。还原时，它会生成一个空的 QMgr，应用程序可以像以前一样连接到该 QMgr。主要要求是应用程序（或人工流程）必须协调任何丢失的消息。

有一种灾难恢复方法可以实现零恢复点——即不丢失任何消息。这使用 QMgr 文件下的同步磁盘复制。对队列或日志文件的每次更新都会实时复制到灾难恢复站点，因此 DR QMgr 具有主 QMgr 的精确副本。当主服务器出现故障时，您会中断复制并启动 DR QMgr。假设您的 DNS 也配置为故障转移，所有远程 QMgr 和程序都将使用 DR QMgr，就好像它是主要的一样。

还有几个 HA 选项。使用 PowerHA 或 Veritas Cluster Server 等硬件集群可以将 QMgr 从一台服务器故障转移到另一台服务器，前提是 QMgr 的文件托管在 SAN 等高可用性磁盘上。Multi-Instance QMgr 可以在没有硬件集群软件的情况下执行类似的故障转移，并且基于高度可用的 NFS 存储。这些都是 HA 解决方案而不是 DR 解决方案，因为两个 QMgr 实例都看到相同的磁盘存储。因此，它们与该磁盘存储的距离必须接近相同的距离（在网络方面），否则最远的 QMgr 上的性能将受到延迟的影响，并且吞吐量可能无法接受。

信息中心的可用性、恢复和重新启动主题中提供了其他信息。

于 2012-08-21T17:51:09.297 回答