I have one MQ cluster environment. At some point, one of the partial repository qmgr broke down while the queue SYSTEM.CLUSTER.REPOSITORY.QUEUE's depth in another qmgr keeps increasing.
I kind of don't undersatnd why this happened. I walked through the technote from this link http://www-01.ibm.com/support/docview.wss?uid=swg21193012 but I don't understand it. Can someone help explain in more detail and more clearly?
Thanks
The repository queue contains messages that represent the state of the cluster. The full repository tracks state of all objects and QMgrs in the cluster while the cluster member QMgrs track only the objects they need to know about. Since this is usually a subset, ordinary cluster QMgrs are sometimes referred to as "partial repositories" because that is what they contain - a partial subset of the full repository info.
The actual format of the messages on the repository queue is not publicly documented. What the Technote explains is that the information is frequently rearranged and compressed so that you should not expect a linear relationship between the number of cluster objects and the depth of the repository queue. Depending on the timing, one message on the repository queue might represent the state of multiple cluster objects or just one. There might even be repository messages representing the state of deleted cluster objects. Generally, partial repositories have fewer messages on the repository queue than do full repositories but if not it usually is not any indication of a problem.
What the Technote doesn't explain is that the messages on the repository queue are held under syncpoint and that this distorts the QDepth. For example, the QMgr will read all the cluster repository messages at startup. If it needs to make a change, it performs a GET under syncpoint for the relevant message(s). During the time when these messages are under syncpoint, the queue depth is reduced even though the messages are still there. The apparent and actual depths will match only after a COMMIT or ROLLBACK. As the cluster state changes, new messages are put to the queue to reflect the new state. These increase the apparent QDepth immediately, even while the transaction is pending COMMIT or ROLLBACK. Also, the number of messages written may be significantly more or less than the number gotten for any update of the queue.
So the upshot of the Technote and my advice is to accept that the SYSTEM.CLUSTER.REPOSITORY.QUEUE is volatile and not to worry to much about its depth. Instead, if you have a monitoring agent, monitor that there is always an open input handle on the queue or that the cluster repository manager process (amqrrmfa) is running, or both.