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