Ibm mq webspheremq集群工作负载平衡：消息进入死信队列

我已经创建了一个带有3个QMGR的WMQ集群。2个完整存储库和1个部分存储库。以下是使用的

mqsc

：

crtmqm GW
strmqm GW
runmqsc GW
alter qmgr deadq('SYSTEM.DEAD.LETTER.QUEUE')
define listener(gw.listener) trptype(TCP) port(1416) ipaddr(xx.xx.xx.xx)
start listener(gw.listener)
define channel(SYSTEM.ADMIN.SVRCONN) chltype(svrconn)
ALTER QMGR CHLAUTH(DISABLED)
end

runmqsc QM01
alter qmgr repos('DEVELOPMENT.CLUSTER')
end

runmqsc QM02
alter qmgr repos('DEVELOPMENT.CLUSTER')
end

runmqsc QM01
define chl(to.QM01) chltype(clusrcvr) trptype(tcp) +
       conname('xx.xx.xx.xx(1414)') cluster(DEVELOPMENT.CLUSTER) 
end

runmqsc QM02
define chl(to.QM02) chltype(clusrcvr) trptype(tcp) +
       conname('xx.xx.xx.xx(1415)') cluster(DEVELOPMENT.CLUSTER) 
end

runmqsc GW
define chl(to.GW) chltype(clusrcvr) trptype(tcp) +
       conname('xx.xx.xx.xx(1416)') cluster(DEVELOPMENT.CLUSTER) 
end

runmqsc QM01
DEFINE CHANNEL(TO.QM02) CHLTYPE(CLUSSDR) TRPTYPE(TCP) +
       CONNAME('xx.xx.xx.xx(1415)') CLUSTER(DEVELOPMENT.CLUSTER)
end

runmqsc QM02
DEFINE CHANNEL(TO.QM01) CHLTYPE(CLUSSDR) TRPTYPE(TCP) +
       CONNAME('xx.xx.xx.xx(1414)') CLUSTER(DEVELOPMENT.CLUSTER)
end

runmqsc GW
DEFINE CHANNEL(TO.QM01) CHLTYPE(CLUSSDR) TRPTYPE(TCP) +
       CONNAME('xx.xx.xx.xx(1414)') CLUSTER(DEVELOPMENT.CLUSTER)
DEFINE CHANNEL(TO.QM02) CHLTYPE(CLUSSDR) TRPTYPE(TCP) +
       CONNAME('xx.xx.xx.xx(1415)') CLUSTER(DEVELOPMENT.CLUSTER)
end

runmqsc QM02
define qlocal('BACKUP') CLUSTER(DEVELOPMENT.CLUSTER)
define qlocal('PROVIDER') CLUSTER(DEVELOPMENT.CLUSTER)
define qlocal('RESPONSE') CLUSTER(DEVELOPMENT.CLUSTER)
define qlocal('STORE') CLUSTER(DEVELOPMENT.CLUSTER)
REFRESH CLUSTER(DEVELOPMENT.CLUSTER) REPOS(YES) 
end

runmqsc QM01
define qlocal('BACKUP') CLUSTER(DEVELOPMENT.CLUSTER)
define qlocal('PROVIDER') CLUSTER(DEVELOPMENT.CLUSTER)
define qlocal('RESPONSE') CLUSTER(DEVELOPMENT.CLUSTER)
define qlocal('STORE') CLUSTER(DEVELOPMENT.CLUSTER)
REFRESH CLUSTER(DEVELOPMENT.CLUSTER) REPOS(YES)
end

现在，我在队列

提供者

上向QMgr

GW

发送一条消息。请注意，

GW

不承载此队列。它由

QM01

和

QM02

amqsput PROVIDER GW

不幸的是，所有消息都将进入QMgr

GW

的死信队列

---

请帮忙解决这个问题。任何关于调试的建议都会有很大帮助。

这里有几个可能的问题

通道的定义不相同。有些名称大小写混合，有些名称全是大写。如果您指望缺少引号以确保它们都被QMgr折叠成大写，那么这可能会起作用。但是，这些命令显然已经被编辑过，至少就

CONNAME

值而言是这样，所以我不假设结果对象匹配

创建集群后，是否检查所有频道是否显示为自动显式？这就是您如何知道集群已正确启动的原因

REFRESH CLUSTER

命令也可能导致停机。在定义新对象时，这不是必需的，事实上，这相当具有破坏性。它等待通道重新启动，在您运行该命令的时间点，播发新对象的命令已发送到存储库，但未返回。

REFRESH CLUSTER

然后请求通道停止（可能在批处理过程中）队列命令，以便集群删除其刚刚收到但尚未回复的信息，然后向集群发送新命令，公布其刚刚删除的对象。如果这听起来令人困惑，请思考存储库上的集群命令服务器的感受

从队列定义脚本中删除

REFRESH CLUSTER

命令

一旦确定所有通道都已升级到

自动显式

并删除

刷新群集

，您就可以开始实际调试了。在这些情况下，查看死消息的DLQ头以找出列出的原因码确实很有帮助。这通常提供足够的信息来发现问题。您还可以启用各种QMgr诊断事件，并使用事件查看工具之一查看它们，或查看通道任一端QMgr上的错误日志

---

下面这些建议与您的诊断无关，只是使用最佳实践构建的QMgr通常不太容易出错，并且更容易调试。下面是一些未经请求的MQ集群最佳实践建议

• 放弃

  至[QMGR]

  频道名称！改用

  [cluster].[qmgr]

  名称，例如

  DEVCLUS.QM01

  。这确保了即使有重叠的集群，也始终有专用于每个集群的通道。但是，这确实意味着集群名称中不能包含
  ，并且必须少于10个字符
• 对于不完整的存储库，只为其中一个存储库定义显式的

  CLUSSDR

  。如果您有两个以上的存储库（例如在迁移期间），集群成员将能够通过这种方式找到它
• 在定义中始终使用引号。如果你在工作中遇到问题，那么只有一种可能解释的定义是解决问题的捷径
• 在定义新群集通道时，给通道一段时间来解决问题，并验证它是否启动并进入正确的状态
• 使用

  AMQSPUT

  打开新定义的远程托管集群队列以进行输出，但不实际向它们发送消息。确保在打开过程中没有错误（即队列解析），然后确保群集通道已启动然后执行

  amqsput

  并发送消息

• REFRESH CLUSTER

  是用于部分存储库的命令，而

  RESET CLUSTER

  是用于完整存储库的命令。在这种情况下，该命令使用不当，并且位于错误类型的群集节点上。期待问题
• 希望在现实生活中，完整存储库QMgrs上没有托管的应用程序队列。您可以为集群做的最好的事情是在专用QMGR上托管完整的存储库，即使这些存储库与应用程序QMGR位于同一主机上。将它们分开可以确保集群操作流量和应用程序流量永远不会穿过相同的通道。它还可以在应用程序QMgrs之前修补或升级存储库