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有时称为“部分存储库”，因为这是它们包含的内容 - 完整存储库信息的部分子集。

存储库队列中消息的实际格式未公开记录。 Technote解释说，信息经常被重新排列和压缩，因此您不应该期望集群对象数量和存储库队列深度之间存在线性关系。根据时间的不同，存储库队列中的一条消息可能表示多个集群对象的状态或仅一个。甚至可能存在代表已删除群集对象状态的存储库消息。通常情况下，部分存储库在存储库队列中的消息数少于完整存储库的消息数量，但如果不是，通常不会显示任何问题。

Technote没有解释的是，存储库队列中的消息被保持在同步点之下，并且这会扭曲QDepth。例如，QMgr将在启动时读取所有集群存储库消息。如果需要进行更改，则会在相关消息的同步点下执行GET操作。在这些消息处于同步点时，即使消息仍然存在，队列深度也会降低。表观深度和实际深度只能在COMMIT或ROLLBACK后匹配。随着群集状态的变化，新的消息被放入队列以反映新的状态。即使交易正在等待COMMIT或ROLLBACK，这些会立即增加明显的QDepth。此外，写入的消息数量可能远远多于或少于任何队列更新所获得的数量。

所以Technote的结果和我的建议是接受SYSTEM.CLUSTER.REPOSITORY.QUEUE是不稳定的，不要太在意它的深度。相反，如果您有监视代理程序，请监视队列上总是有打开的输入句柄，或者正在运行集群资源库管理器进程（amqrrmfa），或者两者都运行。