使用 dmpmqcfg 的远程队列管理器备份不起作用

Question

在使用 dmpmqcfg 命令备份远程队列管理器时，我得到 MQSC 超时等待命令服务器的响应。下面是我正在使用的命令。

dmpmqcfg -m <Queue Manager> -r <remote qmgr> -x all -a -o mqsc > D:\RemoteQueueManagerBackup\RemoteQmgr.txt

在运行此命令之前，我在两个队列管理器端创建了一个服务器和请求者通道，执行时上述命令通道进入运行状态，但无法进行备份。

对于少数队列管理器，它工作正常，而对于少数队列管理器，它不工作。我检查了运行 qmgr 之间的所有属性，其他两者看起来都一样。

更新

名称为队列管理器的 Xmitq 队列在两端定义，例如：队列管理器 A Xmitq 作为 B，对于队列管理器 B Xmitq 作为 A。创建服务器和请求者通道。当命令被触发时，通道进入运行状态。

• 从 dmpmqcfg 返回的任何错误？ --- 没有。
• 是否启用了 DLQ 并定义了指定名称的队列？ - 是的
• DLQ 两端是否存在消息？ - 消息被存储在远程队列管理器死信队列中。
• 两个 QMgrs 之间的通道是否在手动启动时运行（这可能是触发问题而不是名称解析）？ - 通道自动运行（启用触发）否
• 与身份验证相关的错误？我们看到的唯一错误是

AMQ9544：消息未放入目标队列。

解释：在处理通道“x.Y”一个或多个 无法将消息放入目标队列，尝试 将它们放入死信队列。队列的位置是 2，其中1是本地死信队列，2是远程 死信队列

行动：检查 DLQ 的内容。每条消息都包含在 描述为什么将消息放入队列的结构，以及 到它最初的地址。也看看以前的错误 消息以查看将消息放入 dlq 的尝试是否失败。这 处理程序的程序标识符 (PDI) 为 '5608(10796)'

已检查远程死信队列原因： MQRC_PERSISTENCE_NOT_ALLOWED

Answer 1

您没有提及频道及其 XMitQ 的详细信息。为了让消息到达远程机器并得到回复，每个 QMgr 需要能够解析到另一个的路径。这意味着 something 必须具有远程 QMgr 的名称。该东西必须是 XMitQ 本身或指向 XMitQ 的 QMgr 别名。

例如，您有<Queue Manager> 和<remote qmgr>。本地 QMgr 可能有一个名为 <remote qmgr> 的传输队列，用于解析该目标。由于您没有从 dmpmqcfg 报告任何错误，我将假设消息发送正常。

这意味着消息没有返回。这可能是因为远程 QMgr 的 XMitQ 的名称类似于 <Queue Manager>.XMITQ 而不是 <Queue Manager>。这可以通过定义一个 QMgr 别名来解决：

DEF QREMOTE('<Queue Manager>') +
    XMITQ('<Queue Manager>.XMITQ') +
    RNAME(' ') +
    RQMNAME('<Queue Manager>') + 
    REPLACE

如果这确实是问题所在，您应该会在远程 QMgr 上的 DLQ 中看到一些消息 - 假设在 QMgr 属性中定义和指定了一条消息。

如果这不能解决问题，请提供其他信息，包括：

• 从dmpmqcfg 返回的任何错误
• 是否启用了 DLQ 并定义了指定名称的队列
• DLQ 两端是否存在消息
• 手动启动时两个 QMgrs 之间的通道是否运行（这可能是触发问题，而不是名称解析）
• 所涉及的 QMgrs 平台
• 错误日志中的任何相关条目，包括身份验证错误（例如，mqm 在 Linux 上是有效 ID，但在 Windows 上不是，因此如果发送 QMgr 是 Linux 并且远程 QMgr Windows 会在这种情况下生成身份验证错误)

更新回应有问题的其他信息
所以看起来你至少有几个问题。您发现的一个是临时动态队列不接受持久消息。如果你仔细想想，这完全有道理。如果消息是持久的，这会告诉 MQ 采取一切预防措施以防丢失它。但是当最后一个输入句柄被释放时，一个临时动态队列被删除，丢弃它持有的任何消息。

任何将持久消息放入临时动态队列的尝试都会向 MQ 发送冲突信号。它是否应该接受它知道将被隐式删除的持久消息？还是不应该删除临时动态队列以保留消息？它不是试图猜测用户的意图，而是简单地禁止该操作。因此，您的持久回复消息到达本地 QMgr，找到一个临时动态队列，然后被转移到 DLQ。

您已经找到了解决此问题的方法。好吧，无论如何，解决这个问题的方法之一——改变DEFPSIST，这样消息就不是持久的。另一种解决方案是使用dmpmqcfg 的客户端连接功能直接连接到远程 QMgr，而不是通过本地 QMgr 进行路由。

对于剩下的几个 QMgrs，您需要再次运行相同的诊断。检查错误消息、两端 DLQ 的深度、正在运行的通道、身份验证错误。请记住，资源错误、身份验证错误、路由问题等可能发生在任一端，因此请在两个 QMgrs 中查找错误消息和错误路由消息。此外，通过向两个 QMgrs 发送消息和从两个 QMgrs 发送消息到已知队列（例如 SYSTEM.DEFAULT.LOCAL.QUEUE）或应用程序队列来验证通道。

在玩“我的消息在哪里”游戏时，另一个有用的技巧是在发送命令之前通过在两个方向上停止通道来跟踪消息流。然后，您可以运行 dmpmqcfg 并查看出站 XMitQ 的深度以验证命令是否已发送。 （如果你想浏览消息，你必须 GET 启用 XMitQ，因为通道代理 GET 禁用它。这将让你验证它们的持久性、到期值等）

假设命令看起来没问题，您只启动出站通道并让消息流到处理它们的远程 QMgr。由于返回通道仍然停止，因此返回 XMitQ 中的回复堆叠。您可以在那里查看它们，以确定它们的持久性、到期时间和命令的返回代码/结果。如果它们看起来不错，请启动频道，然后在本地 QMgr 上查找它们。

对于仍然存在问题的少数 QMgrs，您应该能够轻松找出消息丢失或被丢弃的位置。请记住，非持久性消息是通过任何工作单元之外的通道发送的，因此如果没有有效的目的地（或者它们没有被授权），它们将被静默丢弃。这种在 XMitQ 上捕获它们的诊断方法会隔离每个步骤，以便如果它们被丢弃，您可以找出在哪里以及为什么。