Ibm mq 恢复QMGR时，哪种方法更好？

通常，我们有两种方法来恢复QMGR。一个是备份和恢复QMGR数据和日志，另一个是创建备份QMGR。我的问题是哪一个更适合QMGR恢复情况？或者它们都有自己的使用场景？请帮我回答这个问题

---

谢谢

从什么地方恢复过来？最佳答案取决于这些要求以及应用程序的编写方式。从体系结构的角度来看，最好的方法是将消息传递视为一种传输。备份网络路由器时，不备份路由器上正在传输的消息，只备份路由器配置。队列管理器也是如此。如果备份对象定义、授权、ini文件、出口和出口parms，则可以重新创建QMgr的空版本，并在旧版本停止的地方继续

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

主队列管理器上的消息与备份队列管理器上的消息之间始终存在延迟，该延迟由主活动日志扩展数据块和辅助活动日志扩展数据块消耗的空间表示。如果主日志扩展数据块和辅助日志扩展数据块的大小和数量保持较小，则可以将故障切换中丢失的消息数量降至最低。通过这种方式无法实现零恢复点，但它比时间点备份要好得多

这就引出了您提到的另一种备份方法。如果在QMgr运行时进行备份，则时间点备份（即备份QMgr的队列和日志文件）无法工作。在繁忙的QMgr上，日志和队列不断写入，并且必须同步。但在活动状态下备份这些文件几乎可以保证备份的日志不会与备份的队列同步。QMgr可能会使用损坏的队列进行恢复，或者在恢复后QMgr甚至不会启动

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

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

• 对象定义
• 授权书
• 退出目录
• 出口parms
• ini文件

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

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

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

---

更多信息可在信息中心的主题中找到。

从何处恢复？最佳答案取决于这些要求以及应用程序的编写方式。从体系结构的角度来看，最好的方法是将消息传递视为一种传输。备份网络路由器时，不备份路由器上正在传输的消息，只备份路由器配置。队列管理器也是如此。如果备份对象定义、授权、ini文件、出口和出口parms，则可以重新创建QMgr的空版本，并在旧版本停止的地方继续

不幸的是，大多数应用程序都是ar