使用dmpmqcfg进行远程队列管理器备份不起作用-Java 学习之路

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

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

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

对于一些队列管理器来说，它的工作正常，而且很少有它不能工我检查了运行qmgr和其他两个看起来相同之间的所有属性 .

Update

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

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

AMQ9544：未将消息放入目标队列 . 说明：在处理通道“x.Y”期间，无法将一条或多条消息放入目标队列，并尝试将它们放入死信队列 . 队列的位置是2，其中1是本地死信队列，2是远程死信队列操作：检查DLQ的内容 . 每条消息都包含在一个结构中，该结构描述了消息放入队列的原因以及最初寻址的位置 . 另请查看以前的错误消息，以查看将消息放入dlq的尝试是否失败 . 处理程序的程序标识符（PDI）是'5608（10796）'

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

1 回答

1
您没有提及 Channels 及其XMitQ的详细信息 . 为了使消息到达远程机器并且回复每个QMgr需要能够解析到另一个的路径 . 这意味着某些东西必须具有远程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平台
- 错误日志中的任何相关条目，包括auths错误（例如， mqm 在Linux上是有效ID但在Windows上不是，因此如果发送QMgr是Linux和远程QMgr Windows，则会在此方案中生成auths错误）
Update responding to additional info in question
所以看起来你至少有几个问题 . 您发现的是临时动态队列不接受持久消息 . 如果你仔细想想，这就完全有道理了 . 如果消息是持久的，这告诉MQ采取所有预防措施以防丢失它 . 但是，在释放最后一个输入句柄时会删除临时动态队列，并丢弃它所拥有的任何消息 .

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

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

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

播放"where's my message"游戏时另一种有用的技巧是在发送命令之前通过在两个方向上停止通道来跟踪消息流 . 然后，您可以运行 dmpmqcfg 并在出站XMitQ上查看深度以验证命令是否已发送 . （如果要浏览消息，则必须GET启用XMitQ，因为通道代理GET禁用它 . 这将允许您验证它们的持久性，到期值等）

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

对于仍有问题的少数QMgrs，您应该能够轻松找到消息丢失或被丢弃的位置 . 请记住，非持久性消息是通过任何工作单元之外的通道发送的，因此如果没有有效的目标（或者它们没有被授权），它们将被静默丢弃 . 这种在XMitQs上捕获它们的诊断方法会隔离每一步，这样如果它们被丢弃，您可以找到它们的位置和原因 .
回复于 2024-04-28T19:18:59+08:00

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

1 回答

相关问题