IBM Integration Community Come for answers. Stay for best practices. All we’re missing is you. Join / Log in Ask a question
What does it mean if there are messages in SYSTEM.CLUSTER.HISTORY.QUEUE?
The SYSTEM.CLUSTER.REPOSITORY.QUEUE contains the topology of an MQ cluster, as seen from the Queue Manager.In the event of problems on a cluster in production, the REFRSH CLUSTER command can be used to force the reconstruction of this topology. But as a result, the old topology is erased, and IBM cannot investigate what happened.
The SYSTEM.CLUSTER.HISTORY.QUEUE has been available since MQ version 7.0.1, and contains a backup of the SYSTEM.CLUSTER.REPOSITORY.QUEUE. This backup can be used after the fact to determine incidents.
is there a way to investigate or read this queue to see what incidents occurred?
I have 1 repository that has over 1000 messages in this queue.
The number of messages in the SYSTEM.CLUSTER.HISTORY.QUEUE is not important. Each time you REFRESH CLUSTER, the current topology of the cluster is saved in this queue in the form of messages, which are kept for 180 days.So if you have a lot of messages in the SYSTEM.CLUSTER.HISTORY.QUEUE it may be because there have done a lot of CLUSTER RESETs?
I remember that in the past there was a utility that allowed you to dump and see the contents of the system.cluster.repository.queue, but I can't remember the name.Perhaps by opening an IBM support ticket?
But if you're looking for problems, the answers can be found in the AMQERRs and also in the results of the DISPLAY CLUSQMGR commands.
Thanks for your valuable input. I wish there was a cluster health check.
I see lots of these:
"Update not received for object"
"MQ9469W: Update not received for CLUSRCVR channel"
The MQ cluster is a very reliable technology, but it needs to be finely configured, and requires more rigour in its operation than a traditional DQM configuration.A good knowledge of MQ cluster mechanisms is necessary to avoid problems, as some operations are more sensitive than others: deleting/creating a Queue Manager that is a member of a cluster, backing up and especially restoring a Queue Manager that is a member of a cluster, etc.For example, if you restore a backup (MQSC config + datas + logs) of a Queue Manager without taking precautions, it will not receive the configuration changes made in the meantime, and the changes it pushes to full repo may be ignored.This can cause the kind of symptoms you're having, as the Full Repo worry that they haven't received renewals for certain objects.