我有一个 MQ 集群环境。在某些时候，一个部分存储库 qmgr 发生故障，而SYSTEM.CLUSTER.REPOSITORY.QUEUE另一个 qmgr 中的 queue 深度不断增加。
我有点不明白为什么会这样。我从这个链接http://www-01.ibm.com/support/docview.wss?uid=swg21193012浏览了技术说明， 但我不明白。有人可以帮助更详细，更清楚地解释吗？
谢谢
问问题
2458 次
1 回答
5
存储库队列包含表示集群状态的消息。完整存储库跟踪集群中所有对象和 QMgrs 的状态，而集群成员 QMgrs 仅跟踪他们需要了解的对象。由于这通常是一个子集，普通集群 QMgrs 有时被称为“部分存储库”，因为这就是它们包含的内容 - 完整存储库信息的部分子集。
存储库队列上消息的实际格式没有公开记录。技术说明解释的是，信息经常被重新排列和压缩，因此您不应期望集群对象的数量与存储库队列的深度之间存在线性关系。根据时间的不同，存储库队列上的一条消息可能代表多个集群对象的状态或仅代表一个。甚至可能有代表已删除集群对象状态的存储库消息。通常，部分存储库在存储库队列上的消息少于完整存储库，但如果没有，通常不会表明存在问题。
技术说明没有解释的是存储库队列上的消息被保存在同步点下，这会扭曲 QDepth。例如，QMgr 将在启动时读取所有集群存储库消息。如果它需要进行更改，它会在同步点下为相关消息执行 GET。在这些消息处于同步点之下期间，即使消息仍然存在，队列深度也会减少。COMMIT只有在 a或之后，表观深度和实际深度才会匹配ROLLBACK。随着集群状态的变化，新消息被放入队列以反映新状态。这些会立即增加明显的 QDepth，即使在事务待处理COMMIT或ROLLBACK. 此外，写入的消息数量可能明显多于或少于任何更新队列所获得的数量。
所以 Technote 的结果和我的建议是接受 SYSTEM.CLUSTER.REPOSITORY.QUEUE 是易变的，不要太担心它的深度。相反，如果您有监控代理，请监控队列上是否始终存在打开的输入句柄或集群存储库管理器进程 ( amqrrmfa) 是否正在运行，或两者兼而有之。
于 2012-09-06T16:59:11.640 回答