ibm-mq - MQ SYSTEM.CLUSTER.REPOSITORY.QUEUE深度不断增加

Question

我有一个 MQ 集群环境。在某个时刻，其中一个部分存储库 qmgr 发生故障，而另一个 qmgr 中的队列 SYSTEM.CLUSTER.REPOSITORY.QUEUE 深度不断增加。

我有点不明白为什么会发生这种情况。我通过此链接浏览了技术说明http://www-01.ibm.com/support/docview.wss?uid=swg21193012 但我不明白。有人可以帮忙解释得更详细、更清楚吗？

谢谢

Answer 1

存储库队列包含表示集群状态的消息。完整存储库跟踪集群中所有对象和 QMgrs 的状态，而集群成员 QMgrs 仅跟踪它们需要了解的对象。由于这通常是一个子集，因此普通集群 QMgrs 有时被称为“部分存储库”，因为这就是它们所包含的内容 - 完整存储库信息的部分子集。

存储库队列上消息的实际格式未公开记录。技术说明解释的是，信息经常被重新排列和压缩，因此您不应期望集群对象的数量和存储库队列的深度之间存在线性关系。根据时间的不同，存储库队列上的一条消息可能代表多个集群对象的状态，也可能只代表一个集群对象的状态。甚至可能有代表已删除集群对象状态的存储库消息。一般来说，部分存储库在存储库队列上的消息少于完整存储库，但如果不是这样，通常并不表示存在问题。

技术说明没有解释的是，存储库队列上的消息保存在同步点下，这会扭曲 QDepth。例如，QMgr 将在启动时读取所有集群存储库消息。如果需要进行更改，它会在同步点下对相关消息执行 GET。当这些消息处于同步点期间，即使消息仍然存在，队列深度也会减少。仅在 COMMIT 或 ROLLBACK 后，表观深度和实际深度才会匹配。当集群状态发生变化时，新消息将被放入队列以反射(reflect)新状态。即使事务处于挂起的 COMMIT 或 ROLLBACK 状态，这些也会立即增加表观 QDepth。此外，写入的消息数量可能明显多于或少于队列任何更新所获取的消息数。

因此，技术说明的结果和我的建议是接受 SYSTEM.CLUSTER.REPOSITORY.QUEUE 是不稳定的这一事实，不要太担心它的深度。相反，如果您有监控代理，请监控队列上始终存在打开的输入句柄或集群存储库管理器进程 (amqrrmfa) 正在运行，或两者兼而有之。